[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xattr and acl support in ls
From: |
Pádraig Brady |
Subject: |
Re: xattr and acl support in ls |
Date: |
Wed, 23 Apr 2014 11:34:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
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.