Interaction between chmod(), and ACL changing

[Andreas Gruenbacher]

On Fri, 22 Sep 2000, Robert Watson wrote:

> 
> While experimenting with the FreeBSD/TrustedBSD ACL implementation, I
> observed the following counter-intuitive behavior.
> 
> The FreeBSD ACL implementation modifies ufs_chmod(), which is called from
> ufs_setattr() (via VOP_SETATTR)).  When ufs_chmod() is invoked, if ACLs
> are available on the file system, then the ACL_TYPE_ACCESS ACL on the
> object is retrieved.  The following updates from 23.1.2 are performed:
> 
> (1) The corresponding permissions associated with the ACL_USER_OBJ entry
>     shall be set equal to each of the file owner class permission bits.
> 
> This is a nop as I keep the *_OBJ and ACL_OTHER entries in the inode
> permissions anyway.
> 
> (2) If the ACL does not contain an ACL_MASK entry, then the corresponding
>     permissions associated with the ACL_GROUP_OBJ entry shall be set equal
>     to each of the file group class permission bits. 
> 
> To perfom this, I retrieve the ACL, iterate to identify the ACL_MASK if
> any.  If it is not present, the group bits in the inode mode are updated.
> 
> (3) If the ACL contains an ACL_MASK entry, then the corresponding
>     permissions associated with the ACL_MASK entry shall be set equal to
>     each of the file group class permission bits and the permissions
>     associated with the ACL_GROUP_OBJ entry shall not be modified.
> 
> If the ACL_MASK was found above, it is updated with the permissions, and
> ip->i_mode's group entries are used instead of being updated per the new
> mode.  The ACL is written out to disk if a change has occured.
> 
> (4) The corresponding permissions associated with the ACL_OTHER entry
>     shall be set equal to each of the file other class permission bits.
> 
> This is a nop since I keep the ACL_OTHER permissions in the mode anyway.

I read the draft as follows:

The file mode permission bits for the classes user, group, and others each
correspond to exactly one ACL entry at any one time. If the ACL contains
an ACL_MASK entry, the mapping is as follows:

user    <->  ACL_USER_OBJ
group   <->  ACL_GROUP_OBJ
others  <->  ACL_OTHER

If the ACL contains an ACL_MASK entry, the mapping is as follows:

user    <->  ACL_USER_OBJ
group   <->  ACL_MASK
others  <->  ACL_OTHER

The file mode permission bits are always in sync with the permissions of
the corresponding ACL entries. The file mode group permission bits in one
case mirror the ACL_MASK ACL entry, and in the other case the
ACL_GROUP_OBJ ACL entry.

This mapping ensures the file mode permission bits always are a superset
of the effective permissions as granted by the ACL. This ensures chmod
still follows the principle of least surprise, i.e, chmod 700 does the
same thing traditionally and with ACLs.

A weird and unspecified is the case when the ACL_MASK entry is explicitly
removed from a file's ACL using setfacl (I'm only showing only the
relevant entries here):

ACL_GROUP_OBJ  g::rwx
ACL_MASK       m:r-x

This grants r-x to the owning group before, and would grant rwx
afterwards. In that case I'm setting the new ACL_GROUP_OBJ entry
permissions to the union of both entries (g::r-x) in the setfacl utility
(that's what I would expect as a user). The DS17 ACL handling functions do
not treat this case differently.

This mapping would become a lot more complicated with additional
permissions (other than rwx) in the ACL.

> On a similar note, if an ACL change modifies permissions (but not
> ownership) for ACL_USER_OBJ or ACL_GROUP_OBJ, should the
> {setuid,setgid,sticky} bits be removed from the inode?  CAP_FSETID covers
> the case where their is a chown/chgrp operation, but it is always assumed
> the chmod() will explicitely define all of the bits, rather than some of
> the bits being modified as a result of the ACL operation.

I did not implement such interactions, and I think it would be wrong.


Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message