GNU bug report logs - #14283
ls: display presence of capabilities on a file

Previous Next

To reply to this bug, email your comments to 14283 AT debbugs.gnu.org.

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

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: RFE: ls should display presence of capabilities on a file
Date: Fri, 26 Apr 2013 19:26:01 -0700

Just as 'l's displays the presence of access lists by putting a
'+' after the normal mode-bits, perhaps it could put a '^' after
mode-bits to indicate capabilities are set.

I'm aware that if I'm on a color terminal I can get an indication
of this, but color is often off (run through pipes, or not on
color term, or by default).

for SUID/GUID one gets an indicator of s/S in the modebits, so
thought '^' might be reasonable to indicate cap-elevation bits?

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 14283 <at> debbugs.gnu.org
Subject: Re: bug#14283: RFE: ls should display presence of capabilities on
	a file
Date: Sat, 27 Apr 2013 10:35:49 +0100

severity 14283 wishlist

On 04/27/2013 03:26 AM, Linda Walsh wrote:
> Just as 'l's displays the presence of access lists by putting a
> '+' after the normal mode-bits, perhaps it could put a '^' after
> mode-bits to indicate capabilities are set.
> 
> I'm aware that if I'm on a color terminal I can get an indication
> of this, but color is often off (run through pipes, or not on
> color term, or by default).
> 
> for SUID/GUID one gets an indicator of s/S in the modebits, so
> thought '^' might be reasonable to indicate cap-elevation bits?

Yes, in general colors aren't a good mechanism to indicate permissions.
I prefer to highlight portions of the permissions string,
which is more direct and obvious. See http://www.pixelbeat.org/scripts/l

But we have to be a bit careful adding to the permissions string,
for compat reasons etc. I do like the idea of ^ (hat) => cap.
You could even be fancy and use combining hat (\u0302) so
as to not take up any more place, though combining char support
is not currently supported well enough to allow that I think.

We'll consider it,
thanks,
Pádraig.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#14283: RFE: ls should display presence of capabilities on a
	file
Date: Sat, 27 Apr 2013 10:12:32 -0700

Pádraig Brady wrote:

> But we have to be a bit careful adding to the permissions string,
> for compat reasons etc. I do like the idea of ^ (hat) => cap.
> You could even be fancy and use combining hat (\u0302) so
> as to not take up any more place, though combining char support
> is not currently supported well enough to allow that I think.
----
	I would have preferred the combining option as well,
though rejected it for similar reasons. Been using unicode for
10+ years on my file systems (often with many compat issues),
but have only recently started to see more widespread usage
of them on the net...but felt wasn't fully enough supported
to use as an indicator in ls...  In our lifetimes?  ;-)

> We'll consider it,
> thanks,
----
Thank you!

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 14283 <at> debbugs.gnu.org
Subject: Re: bug#14283: RFE: ls should display presence of capabilities on
 a file
Date: Fri, 01 Aug 2014 12:54:14 +0100

On 04/27/2013 10:35 AM, Pádraig Brady wrote:
> severity 14283 wishlist
> 
> On 04/27/2013 03:26 AM, Linda Walsh wrote:
>> Just as 'l's displays the presence of access lists by putting a
>> '+' after the normal mode-bits, perhaps it could put a '^' after
>> mode-bits to indicate capabilities are set.
>>
>> I'm aware that if I'm on a color terminal I can get an indication
>> of this, but color is often off (run through pipes, or not on
>> color term, or by default).
>>
>> for SUID/GUID one gets an indicator of s/S in the modebits, so
>> thought '^' might be reasonable to indicate cap-elevation bits?
> 
> Yes, in general colors aren't a good mechanism to indicate permissions.
> I prefer to highlight portions of the permissions string,
> which is more direct and obvious. See http://www.pixelbeat.org/scripts/l
> 
> But we have to be a bit careful adding to the permissions string,
> for compat reasons etc. I do like the idea of ^ (hat) => cap.
> You could even be fancy and use combining hat (\u0302) so
> as to not take up any more place, though combining char support
> is not currently supported well enough to allow that I think.
> 
> We'll consider it,

There is also the performance issue to consider here.
Currently only can disable coloring or just capability coloring,
which will disable the capability lookup.
This was seen to significantly impact performance:

  $ mkdir testcap
  $ cd testcap
  $ seq 10000 | xargs touch

  $ time ls --color -l >/dev/null
  real 0m0.150s
  $ time LS_COLORS=ca=: ls --color -l >/dev/null
  real 0m0.116s

Though the overhead is decreasing over time:

  Fedora  8 = 30%
  Fedora 15 = 24%
  Fedora 20 = 14%

So I'm leaning towards leaving this enabled now in --long mode
thus allowing to set the permissions flags appropriately.

So what to set? Well we only have a single byte to play with.
Currently we have '.' meaning only SELinux, and '+' meaning anything else.
So I'm thinking we should also have capabilities significant
for outputting the '+'.

This is also tracked at http://bugs.debian.org/756712

thanks,
Pádraig.

Previous Next

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