lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ