Bug 647786

Summary: ls should show an indicator when there are file capabilities associated with a file
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: coreutilsAssignee: Kamil Dudka <kdudka>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: james.antill, jantill, kdudka, ovasik, pebolle, pp, scottt.tw, sgrubb, tmraz, twaugh
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-15 10:31:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Daniel Walsh 2010-10-29 08:57:08 EDT
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.
Comment 1 Kamil Dudka 2010-10-29 09:13:09 EDT
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
Comment 2 James Antill 2010-10-29 09:21:02 EDT
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...
Comment 3 Kamil Dudka 2010-10-29 09:28:19 EDT
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.
Comment 4 Pekka Pietikäinen 2010-10-29 10:01:13 EDT
Is allowed by IEEE Std 1003.1-2004 btw:


-    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.
Comment 5 Paul Bolle 2010-11-07 07:49:47 EST
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.
Comment 6 Kamil Dudka 2010-11-07 08:42:30 EST
Typo fixed, thanks for the notice.
Comment 7 Kamil Dudka 2012-07-22 09:12:58 EDT
upstream position:

Comment 8 James Antill 2012-07-23 16:41:50 EDT
 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)?
Comment 9 James Antill 2012-07-23 16:43:43 EDT
 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).
Comment 10 Ondrej Oprala 2013-04-02 11:09:04 EDT
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.
Comment 11 Ondrej Vasik 2013-08-15 10:11:24 EDT
^ was proposed for the capabilities identification and the item is in upstream todo list.
Comment 12 Fedora Admin XMLRPC Client 2016-06-13 05:04:53 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Kamil Dudka 2016-06-15 10:31:59 EDT
(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.