change_sacl_perms() and ACLs from Solaris to 2.6 Linux
c182driver9 at gideon.org
Tue Oct 3 02:55:10 GMT 2006
On Mon, 02 Oct 2006 22:14:06 -0400, Matt McCutchen wrote:
> 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.
There's some oddity about this in Solaris too, but I don't recall the
details. If a file is in a certain state, one cannot have separate group
and mask bits.
> 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-).
I don't understand what you mean by "inconsistent" here, as rsync 2.6.2
does replicate the Solaris ACL on Linux. If there were some limitation on
Linux's file systems, this couldn't occur.
I do see that if I do something like "chmod g-r" on Linux, this modifies
the mask (as opposed to the group). On Solaris, the same operation
modifies *both* mask and group.
But this is just in the mapping of chmod operations onto ACLs. I'd not
consider it a matter of consistency, unless I'm missing something.
This does explain, though, how do_chmod() is "breaking" the ACL. But not
> 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.
I'm not following that. When I modified the setting of the mask
within change_sacl_perms(), the proper thing did occur on the file I was
moving. But I didn't try this from Linux to Linux, so that might have
> 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.
If you mean that the "g::" ACL should be correct even though an "ls -l"
would yield different results, then I suppose I agree. Again, though, I
didn't have this problem in 2.6.2. So I don't know what changed to
"break" the behavior that, as far as I could tell for quite a while,
> 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.)
This doesn't seem sufficient, as it is apparently what I've already done.
It did solve the file problem (though, as I said, I didn't give it a lot
of diverse testing), but not the directory problem. That second processing
of the directory, which triggered the call to do_chmod(), "broke" the
directory's ACL (which had been correct up to that moment).
> 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.
Both solutions sound like work-arounds for a problem that could be
avoided. Why not simply not use chmod() for files being received with
More information about the rsync