Re: xattr and acl support in ls

[Pádraig Brady]

On 04/21/2014 09:13 PM, Pádraig Brady wrote:
> Thanks for the details.
> I can see the usefulness of displaying all meta data together.
> I presume one can specify -e and -@ together also?
> More notes below...
> 
> On 04/21/2014 07:49 PM, April Arcus wrote:
>> Feature request per @pixelbeat_ ( 
>> https://twitter.com/pixelbeat_/status/458221138964127745 )
>>
>> Apple's fork of FreeBSD's ls supports the options -@ and -e to show extended 
>> attributes and access control lists, respectively:
>>
>> Zephyr:~ ril$ /bin/ls -lFh -e ~
>> total 2944
>> drwxr-xr-x    4 ril  staff   136B Feb 17 16:06 Applications/
>> drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
>> drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
>> drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
>> drwx------@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
>>  0: group:everyone deny delete
>> drwx------+  30 ril  staff   1.0K Feb 17 15:47 Documents/
>>  0: group:everyone deny delete
>> drwx------+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/
>>  0: group:everyone deny delete
> 
> So the extended attributes indicator '@' will override the ACLs indicator '+'.
> That's a general awkwardness about trying to indicate many things
> with a single character. In this case the ambiguity is resolved
> by also listing the ACLs.
> 
> For reference GNU considers access meta data for this character,
> with . implying just a security context, and + indicating anything else
> (i.e. and/or ACLs).
> 
>> Zephyr:~ ril$ /bin/ls -lFh -@ ~
>> total 2944
>> drwxr-xr-x    4 ril  staff   136B Feb 17 16:06 Applications/
>> drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
>>      com.apple.FinderInfo      32B
>> drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
>> drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
>>      com.apple.FinderInfo      32B
>>      org.BasiliskII.ExtendedFinderInfo         16B
>>      org.BasiliskII.FinderInfo         16B
>> drwx------@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
>>      CDQJEIS1UO5TGNv0Q2Y_dvi9Ui8Oe2bc=        235B
> 
> Interesting. In this case you wouldn't know that Desktop/ had ACLs,
> so personally I would have changed the '@' to '+' in this case
> as displaying the xattrs would resolve that ambiguity.
> 
>> drwx------+  30 ril  staff   1.0K Feb 17 15:47 Documents/
>> drwx------+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/
> 
>> coreutils ls can detect the presence of an ACL, but cannot display it, and 
>> is oblivious to xattrs:
>>
>> Zephyr:~ ril$ /usr/local/Cellar/coreutils/8.22/bin/gls -lFh ~
>> total 1.5M
>> drwxr-xr-x    4 ril staff  136 Feb 17 16:06 Applications/
>> drwxr-xr-x    5 ril staff  170 Mar 31 20:39 Applications (Parallels)/
>> drwxr-xr-x  156 ril staff 5.2K Nov  9  2011 CS3 Fonts/
>> drwxr-xr-x   16 ril staff  544 Dec 11 23:35 Classic/
>> drwx------+  63 ril staff 2.1K Apr 19 14:35 Desktop/
>> drwx------+  30 ril staff 1020 Feb 17 15:47 Documents/
>> drwx------+ 179 ril staff 6.0K Apr 21 10:52 Downloads/
>>
>> I am currently using a kludgy shim to dynamically switch between BSD and GNU 
>> ls depending on the passed in flags ( 
>> https://gist.github.com/AprilArcus/11124713 ) - it would be great if 
>> coreutils supported these features, so that I could stop doing this ^^
> 
> So something that might be useful as a first step to both ls(1) and stat(1)
> would be to at least indicate the presence of extended attributes.
> Note often security contexts and ACLs are implemented using extended 
> attributes,
> to that would further complicate things. I don't know the implementation
> details of ACLs on HFS+ for example, and whether they're separate.

Some more notes on this..

There are slightly different APIs for listing xattrs on OSX:

  #include <sys/types.h>
  #include <sys/xattr.h>
  ssize_t listxattr(const char *path, char *namebuf, size_t size, int options);
  ssize_t flistxattr(int fd, char *namebuf, size_t size, int options);
  options = XATTR_SHOWCOMPRESSION | XATTR_NOFOLLOW

and GNU:

  #include <sys/types.h>
  #include <attr/xattr.h>
  ssize_t listxattr (const char *path, char *list, size_t size);
  ssize_t llistxattr (const char *path, char *list, size_t size);
  ssize_t flistxattr (int filedes, char *list, size_t size);

gnulib could be updated to abstract the differences away.

Another thing to possibly consider indicating is the presence of file 
capabilities,
which GNU ls now does (IMHO confusingly/inconsistently) with colors.
http://man7.org/linux/man-pages/man2/capget.2.html
Note these are usually implemented with xattrs also.
capabilities indication is tracked at http://bugs.gnu.org/14283

We should be able to come up with something here to at least indicate
the presence of xattrs or capabilities.

POSIX says about the indication character:

"The <optional alternate access method flag> shall be the empty string if there 
is no alternate
or additional access control method associated with the file; otherwise, it 
shall be a string
containing a single printable character that is not a <blank>."

So we'd need to maintain this as a single char to avoid breaking scripts that 
parse ls output.

To summarize these chars:
 '.' = security context
 '+' = ACL (and optionally security context)
 '@' = other extended attributes

So how about we don't distinguish capabilities with a separate char,
and instead indicate with '@' since capabilities are generally implemented
with extended attributes. Note one can't see which capabilities
are present when listing xattrs:

  $ touch cap.test
  $ sudo setcap cap_net_raw+ep cap.test
  $ getfattr -m- -d cap.test
  # file: cap.test
  security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
  security.selinux="unconfined_u:object_r:user_home_t:s0"

Though one can see that it's a capability, which can be further interpreted:

  $ getcap cap.test
  cap.test = cap_net_raw+ep

To implement the above, we'd have to filter ACL xattrs from others :(

  $ touch acl.test
  $ setfacl -m u:nobody:r acl.test
  $ getfattr -m- -d !$
  # file: acl.test
  security.selinux="unconfined_u:object_r:user_home_t:s0"
  
system.posix_acl_access=0sAgAAAAEABgD/////AgAEAGMAAAAEAAYA/////xAABgD/////IAAEAP////8=

  $ getfacl !$
  ...
  user:nobody:r--
  ...

Also we'd have to be wary about the performance of this:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00006.html

thanks,
Pádraig.