rsync - Oct 2006 - change_sacl_perms() and ACLs from Solaris to 2.6 Linux

I've found an error: ACLs are not properly preserved when a file is moved
from Solaris to a 2.6 Linux (I'm testing using CentOS 4 update 3 plus
updates).  This is using 2.6.8 built with the acl patch on both platforms.

The file on the source Solaris machine:

[truffle:/opt]# getfacl /xxx/x

# file: /xxx/x
# owner: root
# group: other
user::rw-
user:httpd:r-x          #effective:r--
group::r--              #effective:r--
mask:rw-
other:---


and on the destination:

[root@backup1 truffle]# getfacl /backup/truffle/xxx.10/x
getfacl: Removing leading '/' from absolute path names
# file: backup/truffle/xxx.10/x
# owner: root
# group: bin
user::rw-
user:407:r-x                    #effective:r--
group::r--
mask::r--
other::---

The problem only appears to arise when the "main" group and mask bits
are
not the same.  The data is received correctly, but is "mangled" by
change_sacl_perms(), which is being called within set_acl().

The piece of code in change_sacl_perms() which is causing the problem is
apparently:

	                case SMB_ACL_MASK:
	#ifndef ACLS_NEED_MASK
	                        /* mask is only empty when we don't need it. */
	                        if (racl->mask == ACL_NO_ENTRY)
	                                break;
	#endif
	                        COE2( store_access_in_entry,((mode >> 3) & 7,
entry) );
	                        break;

As far as I can tell, this is setting the mask value based upon the file's
group mode.  But I don't know why that would be desired.  So I'm not
sure
what to do to fix this problem.

Any help, please?

I'm wondering if the test is wrong, and if it shouldn't be:

	racl->mask != ACL_NO_ENTRY

but that's purely guesswork.

Thanks...

	Andrew

On 10/2/06, Andrew Gideon <c182driver9@gideon.org>
wrote:
> I've found an error: ACLs are not properly preserved when a file is
moved
> from Solaris to a 2.6 Linux (I'm testing using CentOS 4 update 3 plus
> updates).  This is using 2.6.8 built with the acl patch on both platforms.
> [...]
> As far as I can tell, this is setting the mask value based upon the
file's
> group mode.  But I don't know why that would be desired.  So I'm
not sure
> what to do to fix this problem.
Rsync expects that stat(2) on a file whose ACL contains a mask entry
will return the mask entry as the S_IRWXG mode bits.  Perhaps Solaris
returns the group-owner entry no matter what; that would explain the
trouble.  Would you please test and see if this is the case?  I notice
that http://www.suse.de/~agruen/acl/linux-acls/online/ says:

"Solaris ACLs are based on an earlier draft of POSIX 1003.1e, so its
handling of the mask ACL entry is slightly different than in draft 17
for ACLs with only four ACL entries. This is a corner case that occurs
only rarely, so the semantic differences may not be noticeable."

I suppose rsync will have to be creative to make transfers involving
Solaris work correctly.

Matt

On Mon, Oct 02, 2006 at 08:33:18PM -0400, Andrew Gideon
wrote:
> This is using 2.6.8 built with the acl patch on both platforms.
Please try the CVS version patched with the included ACL patch -- it is
in a much better state than the 2.6.8 patch.  I've done some testing of
the code on Solaris, and may have already fixed the bug.  If not, we can
investigate further.

..wayne..

On Mon, Oct 02, 2006 at 10:47:14PM -0700, Wayne Davison
wrote:
> Please try the CVS version patched with the included ACL patch
FYI, I ran a test on a file with the ACLs you mentioned, and it worked
fine coyping it from Solaris to Linux.

..wayne..