Description of problem: James Antill sugests I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
Files with capabilities are already colorized by default when colors are enabled (default for a tty and interactive shell session, through alias ls='ls --color=auto'). James, have you finally resolved your performance problems with this feature? bug 467508
I don't think having colour for caps. is bad, but I don't think it's enough. Is there a significant problem with changing the mode output? Also, due to 467500 I have "CAPABILITY 00" in .dir_colours ... I can probably remove it now, as this is a completely new machine, but...
I am just asking about the performance impact. Nobody else has spotted it for the last two years, so I'd like to know if it was configuration specific. The main difference is that now it can be easily turned off through $LS_COLORS and get back the old behavior. If we make it hardwired, there will be no such choice.
Is allowed by IEEE Std 1003.1-2004 btw: http://www.opengroup.org/onlinepubs/009695399/utilities/ls.html - None of the attributes of 'S', 's', 'T', 't', or 'x' applies. Implementations may add other characters to this list for the third character position. Such additions shall, however, be written in lowercase if the file is executable or searchable, and in uppercase if it is not. Probably something that should be decided upstream, though.
I had trouble finding this report even though I knew it existed. If the typo in the summary would be corrected I might find this one quicker next time (ie, s/capabilties/capabilities/). But I'm not allowed to edit the summary.
Typo fixed, thanks for the notice.
upstream position: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12020#19
I understand the desire that ls should be fast, esp. as people will compare without knowing what it has to do ... and I'd be happy with '+' processing not being their by default with -l. But currently it is, and the info. documentation says: GNU `ls' uses a `.' character to indicate a file with an SELinux security context, but no other alternate access method. A file with any other combination of alternate access methods is marked with a `+' character. ...which would imply that a '+' would appear for a file with setcaps. Also, AIUI, the only way to currently tell is via. the colour difference (and that's decidedly non-obvious to "normal" people). The whole thing is kind of annoying because a lot of people have colours on by default, so the test is "free" but invisible. I can understand the desire not to have --long appear different depending on if colours are used. Maybe have the acl/selinux tests off by default and have a --long-access-methods=yes/no/auto ... where auto turns it on when colours are used (maybe even when the ca attribute is set)?
Also, in reply to comment #3 ... AFAIK I haven't seen the performance problem on other machines. But as I said, the original machine stopped being used and it seemed very FS specific (as copying the data to a new dir. wouldn't ever trigger the problem, IIRC).
I tested ls with and without checking capabilities (--color={yes,no}) on a set of 25000 fresh (so hopefully not yet cached) files with capabilities set and separated into a directory tree of several levels. The difference between runs was less than 0.1s.
^ was proposed for the capabilities identification and the item is in upstream todo list.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to Ondrej Oprala from comment #10) > I tested ls with and without checking capabilities (--color={yes,no}) on a > set of 25000 fresh (so hopefully not yet cached) files with capabilities set > and separated into a directory tree of several levels. The difference > between runs was less than 0.1s. While this might be true for a local file system, there can be much bigger performance penalty for a remote file system. (In reply to Kamil Dudka from comment #7) > upstream position: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12020#19 Nobody has proposed a solution that upstream would like. I do not think myself this proposal is a good idea and will not advocate it upstream. Closing WONTFIX. Feel free to reopen once there is agreement on a solution in the upstream community of GNU coreutils.