Copying EAs and ACLs

Andreas Gruenbacher agruen at
Sun Feb 23 23:13:56 EST 2003


I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
and I've recently been asked about ACL support in rsync by Eric. Upon 
investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
also found some other postings to rsync at concerning rsync and 
ACLs [3].

Are there any plans for finalizing an integrating that rsync ACL patch?

I am posting my own thoughts on that topic with the hope to spur the 
discussion and accelerate the improvement of rsync in that direction.

ACLs are one part of supporting Extended Attributes in general, but they are 
important enough (and difficult enough to do right) to deserve special 
treatment. (I would like to see Extended Attributes in rsync too, of course.) 
Most UNIX systems support some variant of POSIX ACLs. Unfortunately the 
so-far-final draft 17 document the dissolved POSIX 1003.1e/2c working group 
has produced does not define how to deal with ACLs on a network.

Probably partly because POSIX ACLs didn't ever get standardized, the NFSv4 
protocol [4] among other things defines yet another kind of ACLs. NFSv4 ACLs 
are much more like Windows ACLs than POSIX draft 17 ACLs. What's more, the 
NFSv4 protocol not only defines the on-the-wire format to be used for ACLs, 
but also their semantics. This makes them problematic for POSIX ACLs. 
Nevertheless it seems that NFSv4 ACLs are here to stay.

So it seems to make sense to adapt them to POSIX ACLs, and to use them as the 
underlying transfer format for rsync. The SSH File Transfer Protocol 
<> also 
specifies that scp is to use the NFSv4 ACL format, by the way.

Marius Aamodt Eriksen <marius at> has thought out a mapping between 
NFSv4 ACLs and POSIX ACLs [5]. While Marius's mapping most likely is 
semantically correct, I think that it is too complex to be useful 
practically. The main problem is to define a mapping for the POSIX ACL mask 
entry. I would recommend to transfer the ACL MASK entry as a proper ACL entry 
in NFSv4 ACLs with a who field of "MASK@", and to extend the permission 
evaluation mechanism of NFSv4 to take care for this additional entry.

At least as far as rsync is concerned, this proposed approach could be used 
without causing compatibility problems.

Another issue that has surely been considered for rsync is how to map between 
users/groups across different systems. On UNIX like systems this mapping can 
be done based on user/group IDs or names. If it is relevant for rsync to 
transfer both ID's and names between systems, this will be another problem 
with the NFSv4 ACL format.

(In star [6], an implementation of the PAX archive format defined in 
POSIX.1-2001, for storing ACLs, we have been using a text based format which 
is almost identical to what acl_to_text(3) produces, but with ID's added. The 
exact format used is documented in the file README.ACL inside the package. 
This approach is less powerful than NFSv4 ACLs, but good enough for POSIX ACL 

Best regards,
Andreas Gruenbacher.


[1] Buck Huppmann: patch: rsync-2.5.5: UNIX ACL support, 

[2] Gary Fernandez: [PATCH] change rsync to print warning if ACL detected, 

[3] General rsync ACL discussions, 

[4] NFS version 4 Protocol, 

[5] Marius Aamodt Eriksen: Mapping Between NFSv4 and Posix Draft ACLs, 

[6] Jörg Schilling: Star, 

More information about the rsync mailing list