Archiving ACLs on Mac OS X 10.4 doesn't work

[GoogleCodeExporter]

Jesse Peterson reported a problem archiving acls on 10.4.  Below is his
diagnosis from email to xar-devel:
% uname -a
Darwin localhost 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25
19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
% cd /
% sudo fsaclctl -p / -e
% touch foo
% chmod +a 'root allow read' foo
% chmod +a 'root allow write' foo
% ls -le foo
-rw-r--r-- + 1 jesse admin  0 Jan 17 09:41 foo
0: user:root allow read,write
% xar -v -c -f foo.xar foo
foo
% xar --dump-toc=- -f foo.xar
% xar --dump-toc=- -f foo.xar
<?xml version="1.0" encoding="UTF-8"?>
<xar>
<toc>
  <checksum style="sha1">
   <size>20</size>
   <offset>0</offset>
  </checksum>
  <file id="1">
   <name>foo</name>
   <type>file</type>
   <mode>0644</mode>
   <uid>1085</uid>
   <user>jesse</user>
   <gid>80</gid>
   <group>admin</group>
   <atime>2007-01-17T17:41:51Z</atime>
   <mtime>2007-01-17T17:41:51Z</mtime>
   <ctime>2007-01-17T17:53:06Z</ctime>
  </file>
</toc>
</xar>

Interestingly I've found that acl_get_entry appears to be returning 0
for my file in xar-1.4/lib/stat.c:130 which would seem to signify that,
well, there is no ACL entry for the file ;). However, acl_get_file
returns non-null which presumably would indicate that there is an ACL
entry on the file.

In:
http://darwinsource.opendarwin.org/10.4.2/file_cmds-116.9/ls/print.c  
on lines ~ 354 and the function printacl() (lines ~ 252 - 318) appears
to being acl_get_file and acl_get_entry in a very similar way. Which of 
course makes it interesting that "ls -le" prints the ACLs yet the above
is true.

Original issue reported on code.google.com by bbraun on 16 Feb 2007 at 6:04

[GoogleCodeExporter]

Mac OS X 10.4 appears to have non-standard behaviour with regards to its
POSIX.1e-like ACL API. This is a list of the things that I have come accross 
with
regard to xar:

acl_get_entry() Return Values

Section 23.4.14.3 (line 912 of Section 23: "Access Control Lists," page 66)[1] 
states
that when an ACL entry is obtained successfully the function acl_get_entry() 
shall
return a 1. The implementation appears to return 0.

Long Text Form Comments

Section 23.3.1 (line 471 of Section 23: "Access Control Lists," page 51)[1] 
states
that comments start with a pound sign and yet the text representation from an 
ACL
entry appears to start with an "!#acl 1" line whereby the exclamation point 
makes the
entry non-conformant.

Long Text Form undefined/platform-specific ACL qualifier

Section 23.3.1 (line 440 of Section 23: "Access Control Lists," page 51)[1] the 
ACL
qualifiers are platform dependent even though while reviewing the text ACL 
entries
there appears to be no significant need for this - that is the standard 
definition of
the ACL text representation appears to meet the needs of representation put 
forth by
the implementation. The qualifier appears to be some type of UUID.

--
[1] IEEE Std 1003.1e Draft 17 (October 1997).

Original comment by jesse.c....@gmail.com on 18 Feb 2007 at 3:33

[GoogleCodeExporter]

I believe I have resolved this with commit r124 in trunk.

Original comment by bbraun on 17 Apr 2007 at 10:15

• Changed state: Fixed