bug#12020: ls should show when extended system attributes are set
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
bug#12020: ls should show when extended system attributes are set
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
bug#12020: ls should show when extended system attributes are set
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.
bug#12020: ls should show when extended system attributes are set
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
bug#12020: ls should show when extended system attributes are set
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.
bug#12020: ls should show when extended system attributes are set
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
bug#12020: ls should show when extended system attributes are set
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 ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#12020: ls should show when extended system attributes are set
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
bug#12020: ls should show when extended system attributes are set
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
