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.
