GNU bug report logs - #12020
ls should show when extended system attributes are set

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12020 in the body.
You can then email your comments to 12020 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Luk Claes <luk <at> debian.org>
To: bug-coreutils <at> gnu.org
Subject: ls should show when extended system attributes are set
Date: Sat, 21 Jul 2012 20:41:00 +0200

Hi

Currently when using POSIX acls, this is not visible when listing files
with ls. This means that users and system administrators cannot easily
see when (non trivial) POSIX acls are in use which obviously can result
in wrong expectations when only seeing the rwx kind of acls.

At a minimum I would like that ls would show that extended system
attributes are being used (maybe by showing something different than -
for the type of file?).

Cheers

Luk

Message #8 received at 12020 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Luk Claes <luk <at> debian.org>
Cc: 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sat, 21 Jul 2012 15:56:48 -0600

[Message part 1 (text/plain, inline)]

tag 12020 moreinfo
thanks

On 07/21/2012 12:41 PM, Luk Claes wrote:
> Hi
> 
> Currently when using POSIX acls, this is not visible when listing files
> with ls. This means that users and system administrators cannot easily
> see when (non trivial) POSIX acls are in use which obviously can result
> in wrong expectations when only seeing the rwx kind of acls.

What version of coreutils are you using, and on what distro?

> 
> At a minimum I would like that ls would show that extended system
> attributes are being used (maybe by showing something different than -
> for the type of file?).

But ls _does_ already do that.

$ getfacl foo
# file: foo
# owner: eblake
# group: eblake
user::rw-
user:dummy:rw-
group::---
mask::rw-
other::---

$ ls -l foo
-rw-rw----+ 1 eblake eblake 0 Jul 21 15:50 foo
$ setfacl -b foo
$ getfacl foo
# file: foo
# owner: eblake
# group: eblake
user::rw-
group::---
other::---

$ ls -l foo
-rw-------. 1 eblake eblake 0 Jul 21 15:50 foo
$

Notice how the 11th character changed from '+' (ACL present) to '.'
(SELinux label present)?  That is, a trailing '+' is already what
coreutils uses to indicate the presence of ACLs (which generally provide
additional rights); and a trailing '.' indicates the presence of
restrictions (SELinux labels typically restrict rights depending on the
labeling of the calling context).  On systems with neither ACLs nor
SELinux labels, then the 11th character is ' ' (space) to indicate no
other special permissions.

You'll need to provide more information before we can figure out why you
are not finding this information.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #13 received at 12020 <at> debbugs.gnu.org (full text, mbox):

From: Luk Claes <luk <at> debian.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sun, 22 Jul 2012 00:50:12 +0200

On 07/21/2012 11:56 PM, Eric Blake wrote:
> tag 12020 moreinfo
> thanks
> 
> On 07/21/2012 12:41 PM, Luk Claes wrote:
>> Hi
>>
>> Currently when using POSIX acls, this is not visible when listing files
>> with ls. This means that users and system administrators cannot easily
>> see when (non trivial) POSIX acls are in use which obviously can result
>> in wrong expectations when only seeing the rwx kind of acls.
> 
> What version of coreutils are you using, and on what distro?

I'm using Debian, version 8.13

>> At a minimum I would like that ls would show that extended system
>> attributes are being used (maybe by showing something different than -
>> for the type of file?).
> 
> But ls _does_ already do that.

> Notice how the 11th character changed from '+' (ACL present) to '.'
> (SELinux label present)?  That is, a trailing '+' is already what
> coreutils uses to indicate the presence of ACLs (which generally provide
> additional rights); and a trailing '.' indicates the presence of
> restrictions (SELinux labels typically restrict rights depending on the
> labeling of the calling context).  On systems with neither ACLs nor
> SELinux labels, then the 11th character is ' ' (space) to indicate no
> other special permissions.

Nice, though in that case it does apparently not vanish when I only
remove the non-trivial acl again and keep the mask:

$ getfacl foo
# file: foo
# owner: luk
# group: luk
user::rw-
user:mongodb:rw-
group::r--
mask::rw-
other::r--

$ ls -l foo
-rw-rw-r--+ 1 luk luk 5 Jul 22 00:37 foo

$ setfacl -x u:mongodb foo

$ ls -l foo
-rw-r--r--+ 1 luk luk 5 Jul 22 00:37 foo

$ getfacl foo
# file: foo
# owner: luk
# group: luk
user::rw-
group::r--
mask::r--
other::r--

Though I guess it's close enough, only a pitty it's not in the manpage.
So feel free to close this or retarget it.

Cheers

Luk

Message #16 received at 12020 <at> debbugs.gnu.org (full text, mbox):

From: Luk Claes <luk <at> debian.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sun, 22 Jul 2012 01:30:48 +0200

On 07/22/2012 12:50 AM, Luk Claes wrote:
> On 07/21/2012 11:56 PM, Eric Blake wrote:
>> tag 12020 moreinfo
>> thanks
>>
>> On 07/21/2012 12:41 PM, Luk Claes wrote:
>>> Hi
>>>
>>> Currently when using POSIX acls, this is not visible when listing files
>>> with ls. This means that users and system administrators cannot easily
>>> see when (non trivial) POSIX acls are in use which obviously can result
>>> in wrong expectations when only seeing the rwx kind of acls.
>>
>> What version of coreutils are you using, and on what distro?
> 
> I'm using Debian, version 8.13
> 
>>> At a minimum I would like that ls would show that extended system
>>> attributes are being used (maybe by showing something different than -
>>> for the type of file?).
>>
>> But ls _does_ already do that.
> 
>> Notice how the 11th character changed from '+' (ACL present) to '.'
>> (SELinux label present)?  That is, a trailing '+' is already what
>> coreutils uses to indicate the presence of ACLs (which generally provide
>> additional rights); and a trailing '.' indicates the presence of
>> restrictions (SELinux labels typically restrict rights depending on the
>> labeling of the calling context).  On systems with neither ACLs nor
>> SELinux labels, then the 11th character is ' ' (space) to indicate no
>> other special permissions.
> 
> Nice, though in that case it does apparently not vanish when I only
> remove the non-trivial acl again and keep the mask:
> 
> $ getfacl foo
> # file: foo
> # owner: luk
> # group: luk
> user::rw-
> user:mongodb:rw-
> group::r--
> mask::rw-
> other::r--
> 
> $ ls -l foo
> -rw-rw-r--+ 1 luk luk 5 Jul 22 00:37 foo
> 
> $ setfacl -x u:mongodb foo
> 
> $ ls -l foo
> -rw-r--r--+ 1 luk luk 5 Jul 22 00:37 foo
> 
> $ getfacl foo
> # file: foo
> # owner: luk
> # group: luk
> user::rw-
> group::r--
> mask::r--
> other::r--
> 
> Though I guess it's close enough, only a pitty it's not in the manpage.

But it apparently does not show when capabilites are active, could that
be added (or was that added in the meantime in a subsequent version)?

$ setcap cap_chown+ep foo

$ ls -l foo
-rw-r--r-- 1 luk luk 5 Jul 22 00:37 foo

$ sudo getcap foo
foo = cap_chown+ep

Cheers

Luk

Message #19 received at 12020 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Luk Claes <luk <at> debian.org>
Cc: Eric Blake <eblake <at> redhat.com>, 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sun, 22 Jul 2012 14:40:46 +0200

Luk Claes wrote:
...
> But it apparently does not show when capabilites are active, could that
> be added (or was that added in the meantime in a subsequent version)?
>
> $ setcap cap_chown+ep foo
>
> $ ls -l foo
> -rw-r--r-- 1 luk luk 5 Jul 22 00:37 foo
>
> $ sudo getcap foo
> foo = cap_chown+ep

That's right: capabilities are currently not taken into account when
printing ls -l's "optional alternate access method" flag.  However,
with --color, we already do test for the existence of capabilities,
and if found, highlight each affected file differently.

A comment says that the capabilities existence test adds 30% to the cost
of ls --color (it's probably even more, now), so I would not impose it on
ls -l without due consideration.  We know from recent performance-related
improvements that checks like this can have a big impact when operating
on remote file systems.

When already using --color, we do get each test result for free, so it
is tempting to take it into account in that case.  However, that would
make the use of --color change more than just highlighting, but the
actual information displayed, which I would not want to do.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Eric Blake <eblake <at> redhat.com>, bug-coreutils <at> gnu.org,
	Luk Claes <luk <at> debian.org>, 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sun, 22 Jul 2012 15:07:33 +0200

On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote:
> When already using --color, we do get each test result for free

Not really.  The check for file capabilities is optional even with --color.  
The 'ca' indicator in $LS_COLORS needs to be set to a color to enable this.

Kamil

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Kamil Dudka <kdudka <at> redhat.com>
Cc: Eric Blake <eblake <at> redhat.com>, bug-coreutils <at> gnu.org,
	Luk Claes <luk <at> debian.org>, 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Sun, 22 Jul 2012 18:16:39 +0200

Kamil Dudka wrote:
> On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote:
>> When already using --color, we do get each test result for free
>
> Not really.  The check for file capabilities is optional even with --color.
> The 'ca' indicator in $LS_COLORS needs to be set to a color to enable this.

Hi Kamil,

While true that you can disable it,
with the default color settings, that indicator is set,

   $ dircolors --pr |grep CAP
   CAPABILITY 30;41 # file with capability

so with --color, the check is performed unless you arrange
to turn it off.

Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: eblake <at> redhat.com, bug-coreutils <at> gnu.org, luk <at> debian.org,
	12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Mon, 23 Jul 2012 23:25:57 +0200

On Sunday, July 22, 2012 18:16:39 Jim Meyering wrote:
> Kamil Dudka wrote:
> > On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote:
> >> When already using --color, we do get each test result for free
> > 
> > Not really.  The check for file capabilities is optional even with
> > --color.
> > The 'ca' indicator in $LS_COLORS needs to be set to a color to enable
> > this.
> 
> Hi Kamil,
> 
> While true that you can disable it,
> with the default color settings, that indicator is set,
> 
>    $ dircolors --pr |grep CAP
>    CAPABILITY 30;41 # file with capability
> 
> so with --color, the check is performed unless you arrange
> to turn it off.

Yes, there is a default color set for file capabilities.  I just wanted to 
highlight that --color does not imply we check for capabilities on its own. 
The way to skip the check even with --color is there intentionally because
of the following bug:

https://bugzilla.redhat.com/467508

There is also a request similar to this one in Red Hat Bugzilla:

https://bugzilla.redhat.com/647786

Kamil

Message #40 received at 12020 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 12020 <at> debbugs.gnu.org
Subject: Re: bug#12020: ls should show when extended system attributes are set
Date: Tue, 23 Oct 2018 15:58:58 -0600

tags 12020 notabug
close 12020
stop

(triaging old bugs)

On 21/07/12 04:50 PM, Luk Claes wrote:
> [...]
> Though I guess it's close enough, only a pitty it's not in the manpage.
> So feel free to close this or retarget it.
> 

Closing.

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.