rsync - Apr 2003 - [Acl-Devel] mask ACL

Hello Eric,

I am taking Buck and the rsync mailing list into the CC. Buck is the author of 
the rsync patch, he may know more on that problem.

On Wednesday 02 April 2003 00:16, Eric Chen wrote:
> From my understanding, the effecive rights mask 'limits the effective
> rights granted to all groups and to named users', so if you getfacl on
a
> file, the group permissions will be overwritten by the effective rights
> mask permission.
You quote from the getfacl(1) man page, but you misread it. Getfacl does not 
change any permissions. The group permissions are not overwritten.

Please see the acl(5) manual page, particularly section "CORRESPONDENCE 
BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" on the relation between (a) 
what stat(2) reports and `ls -l' displays, and (b) the ACL entries. Also 
check section "ACCESS CHECK ALGORITHM" on the resulting permissions.
There is
also some more extensive coverage under "New ACL chapter in the SuSE
manuals"
and "http://www.suse.de/~agruen/acl/overview/" at 
<http://www.suse.de/~agruen/acl/>.

> # file: winfile
> # owner: 504
> # group: 500
> user::rwx
> group::rw-		#effective:---
> mask::---
> other::rw-
>
> Is there anyway that I can not have the effective rights mask overwrite the
> group permissions?
What Linux implements follows the IEEE 1003.1e specification draft 17. Under 
this interpretation, the above ACL will show with `rwx---rw-' in directory 
listings. What does getfacl show for the original file? I assume it's this 
(header omitted):

	user::rwx
	group::rw-
	other::rw-

If that is indeed the case, then the rsync patch adds a mask entry that is 
wrong.

There are UNIX systems that implement slightly different versions of POSIX 
ACLs, particularly Solaris. Solaris handles ACLs with four entries 
differently. In four-entry ACLs Solaris always has identical permissions in 
the owning group and mask entries. The four-entry ACL you show could map to 
one of the following. All but the first case would hide the problem.

	user::rwx
	group::---
	mask::---
	other::rw-

	user::rwx
	group::rw-
	mask::rw-
	other::rw-

	user::rwx
	group::rw-
	mask::rwx
	other::rw-

ACLs with more that three entries are referred to as extended ACLs. All 
extended ACLs have a mask entry. The mask entry masks the permissions of 
named user entries, named group entries, and the owning group entry. There 
are no exceptions to that.
> I am using rsync with the ACL patch, and when I backup a directory, the
> group permissions are not backed up because the original files do not have
> a mask in the ACL. The resulting files on the backup end up with the ACL
> that is shown above in winfile. Is there anything I can do on the ACL side
> of this problem, or do I have to modify rsync to handle this?
So getfacl only reports three ACL entries for the original files? If this is 
the case then the rsync ACL patch is wrong in adding a fourth entry, and 
needs to be fixed. Note that if I correectly understood Buck this patch is 
more like a band-aid and was never intended to get integrated into rsync.


Cheers,
Andreas.

yes, my bad. sorry. before i throw out more babies with the bathwater,
though, anybody know if any other systems besides HP-UX and Solaris
(for default ACLs, at least) require a MASK/CLASS_OBJ when there are
no non-USER_OBJ/GROUP_OBJ/OTHER entries?

thanks, Eric C., for finding this out

On Tue, Apr 01, 2003 at 11:09:32PM -0500, Buck Huppmann
wrote:
> yes, my bad. sorry. before i throw out more babies with the bathwater,
> though, anybody know if any other systems besides HP-UX and Solaris
> (for default ACLs, at least) require a MASK/CLASS_OBJ when there are
> no non-USER_OBJ/GROUP_OBJ/OTHER entries?
> 
> thanks, Eric C., for finding this out
to wind this up, for anybody who cares, the latest, greatest versions
of this patch are up at http://www.lpmd.org/rsync/ (thanks to John C.
again for hosting) for 2.5.5 and 2.5.6. use at your own risk, but let
me know if you find bugs (so i can mitigate my own risk)

on the matter of which platforms require masks/CLASS_OBJs, i gave the
samba sysacls.c a quick once over and discerned that, at least for
the mappings as implemented therein, HP-UX, Unixware and Solaris re-
quire CLASS_OBJs, which the new code synthesizes by or-ing all group
and named-user ACEs, as you might expect, in the absence of a source
mask/CLASS_OBJ entry