change_sacl_perms() and ACLs from Solaris to 2.6 Linux
hashproduct+rsync at gmail.com
Tue Oct 3 02:14:06 GMT 2006
On 10/2/06, Andrew Gideon <c182driver9 at gideon.org> wrote:
> I also don't know how do_chmod() (which is ACL-ignorant) is changing the mask.
Maybe I didn't make this clear: On Linux, if a file's ACL contains an
ACL_MASK entry, the file's group permission bits (S_IRWXG) are linked
to that entry instead of the ACL_GROUP_OBJ entry. Statting shows the
ACL_MASK entry, and chmodding changes the ACL_MASK entry.
If I understand you correctly, the S_IRWXG mode bits going over the
wire match the Solaris machine's ACL_GROUP_OBJ entry (that is, r--).
>From Solaris's perspective, this is correct. However, from Linux's
perspective, this is inconsistent: the mode bits should match the
ACL_MASK entry (rw-).
Rsync assumes that the received mode bits correspond to the received
ACL according to the Linux convention, and the implementation of
change_sacl_perms is correct under this assumption. In fact,
change_sacl_perms is only necessary because the optimized ACL protocol
omits ACL_USER, ACL_MASK, and ACL_OTHER entries, expecting the
receiver to fill them in from the mode bits.
We should change something so that The Right Thing Happens when a
Solaris rsync sends files to a Linux rsync. I'm assuming we should
preserve the ACL exactly even though the group mode bits on Linux will
be different from the group mode bits on Solaris. I see two possible
fixes. Solaris senders could send an explicit ACL_MASK entry, and
change_sacl_perms could be modified not to override such an entry with
mode bits. (This might be similar to what you were suggesting with
the racl->mask == NO_ENTRY test.) Alternatively, Solaris senders
could pretend their group mode bits were equal to the ACL_MASK and
Solaris receivers could ignore group mode bits in favor of the
ACL_GROUP_OBJ; this might be easier.
More information about the rsync