linux-ext4 - Re: [PATCH] e2p: fix getflags for link file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 5 Dec 2017 21:44:00 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Wang Shilong <wangshilong1991@...il.com>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Shuichi Ihara <sihara@....com>, Wang Shilong <wshilong@....com>
Subject: Re: [PATCH] e2p: fix getflags for link file

On Wed, Dec 06, 2017 at 09:19:26AM +0800, Wang Shilong wrote:
> > But this is one of our customers feedback, this is not good that
> > lsattr/chattr did not support symlink, we might need make it
> > clear, for example, we support symlink, but it always follow
> > original files, that is even better than output errors.

What is the basis of the customer's complaint?  I could imagine
printing a more explanatory message.  So instead of:

lsattr: Operation not supported While reading flags on /foo/bar/baz

maybe:

/foo/bar/baz: file attributes not supported for symlinks

It's not clear to me at all that following symlinks is the right
thing.

> >
> > In this way, we need fix chattr too.
> 
> Just to think more, there is a problem to follow symlink for chattr:
> consider following case that users want to use directory quota:
> 
> dir1/dir1.1         --->project ID is 1
> dir2/dir2.link.1.1 ----->dir2's Project ID is 2, link file to dir1.1
> 
> Considering if users do something like:
> #chattr -p 1 -R dir1
> #chattr -p 2 -R dir2/
> 
> This will break some users expected behavior, since dir1.1
> will be set to project ID 2 which expected as 1.
> 
> So i supposed we should disallow follow symlink for chattr?

... and this is why I don't think we should change the behavior for
lsattr *or* chattr.

I could imagine adding an option which causes lsattr and chattr to
follow symlinks (but in the absense of the option, lsattr and chattr
will do what it does today, which is not follow symlinks, possibly
with a friendly error message), or maybe which causes lsattr to print
something like this:

--------------e---- /usr/bin/emacsclient.emacs24
   <symlink>        /usr/bin/emacs -> /etc/alternatives/emacs

... but honestly, is it really worth it?

					- Ted