change_sacl_perms() and ACLs from Solaris to 2.6 Linux

Andrew Gideon 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--).

Right.

>>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
why.

> 
> 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
problems.

> 
> 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,
worked.

> 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
ACLs?

	- Andrew




More information about the rsync mailing list