chmod and ACLs

[Michael P. Ressler]

In article <473 at longway.TIC.COM>, Bernard Badger Jr. of Harris GISD,
Melbourne, FL raised some comments on chmod and ACLs.  As active
members of the 1003.6 group working on Access Control Lists, we
would like to explain the current PROPOSED 'chmod' behavior when
used on files that contains ACLs.
(Don't worry, it only seems complicated! ;-)

Ana Maria De Alvare' and Mike Ressler
=======


1.  File Group Class Permission Bits

1.1  The Original Scheme

The file permission bits cannot possibly reflect all the
information that can be contained in an ACL.  However, it is
considered desirable that "long directory listings", i.e., "ls
-l", still reflect a reasonable amount of information regarding
the access rights of files.

The approach taken was a compromise.

   The file owner class permission bits will reflect the
   permissions associated with the USER_OBJ entry of the ACL.
   The file other class permissions bits will reflect the
   OTHER_OBJ entry of the ACL.  The file group class
   permission bits will reflect the union of the permissions
   associated with the GROUP_OBJ and all named USER and GROUP
   entries in the ACL.

This method will allow the file permission bits to reflect the
maximum permission that might be granted in the ACL.  Thus
inspection of these bits will not show the exact access rights of
a user but it will show the maximum that the user might have.
For example:

                    mpr     posix   rwxr--r--

indicates exactly what access rights are available to user "mpr"
and also indicates that no other user can "write" the file.

The question of why the file other class is not used instead of
the file group class has been raised several times.  One fallacy
has been that if the ACL were associated with the file other
class, it could be determined exactly what the access for the
owner and owning group of the file would be.  The permission for
the owner would be known, as is the case when the file group
class is used, however the permissions for the group could not be
determined, because a match may occur for a specific user entry
in the ACL (specific users entries are checked before any group
entries).

1.2  Complications due to chmod

Since compatibility with P1003.1 is critical, a chmod function
must change the access rights as currently defined by standard
practice and P1003.1.

   Therefore, the effect of the chmod will be to change the
   USER_OBJ entry of the ACL and the file owner class
   permission bits to the permissions stated in the argument
   of the chmod.  The OTHER_OBJ entry of the ACL and the file
   other class permission bits will also change to the
   permission bits stated in the argument of the chmod.  The
   file group class permission bits will change to the
   permissions stated in the argument of the chmod.  The
   GROUP_OBJ entry of the ACL and the named USER and GROUP
   entries will not be effected by the chmod.

Since the file group permission bits are used as a mask in the
access algorithm, the chmod can be effectively used to limit
permissions on a file without inadvertently trashing the contents
of the ACL.  (The use of the chmod to extend the access rights of
the GROUP_OBJ of the file will not always work as expected.  An
alternative not discussed by the DAC group would be to also
change the GROUP_OBJ ACL entry as a result of the chmod.)

As was just shown, the chmod function can cause the file group
permission bits to no longer reflect the maximum of the
permissions associated with the GROUP_OBJ and all named USER and
GROUP entries in the ACL.  However, due to its use as a mask in
the access algorithm, the file group permission bits will
continue to reflect the maximum permissions granted to non-
USER_OBJ users.

1.3  Complications due to creat

When a file is created using creat, the file permission bits and
associated ACL are created using both the file creation mask
specified as an argument to creat and the default ACL, if
present, in the containing directory.  (The decision to place
default ACLs in the containing directory is discussed in the
"Defaults" section.)  The file permission bits are created as
follows.

   The file owner permission bits are the intersection of the
   USER_OBJ specified in the default ACL and the file owner
   permission bits specified in the file creation mask
   argument of creat.  Similarly, the file other permission
   bits are the intersection of the of the OTHER_OBJ specified
   in the default ACL and the file other permission bits
   specified in the file creation mask argument of creat.  The
   file group permission bits are the intersection of the file
   group permission bits specified in the file creation mask
   argument of creat and the file group permission bits that
   would have been calculated from the GROUP_OBJ and named
   USER and GROUP entries in the default ACL.

   The resulting associated ACL will contain a USER_OBJ and
   OTHER_OBJ entry that reflect the file permission bits
   described above.  The GROUP_OBJ entry and named USER and
   GROUP entries will be copied from the default ACL without
   modification.

The net effect of this process will be access control rights that
reflect the minimum of the creat mode creation mask and the
default ACL.  This seems reasonable as it provides both the owner
of the directory and the author of the software a say in
determining the access rights of the resulting file.

1.4  Undoing the Complication

As shown above, due to the interaction of existing DAC
mechanisms, namely the creat and chmod functions with the ACL
mechanisms, the ACL entries may not truly represent the access
control decisions that will be made.  This condition will exist
whenever the file group permission bits are not equal to the
union of the GROUP_OBJ and the named USER and GROUP entries of
the ACL.  This condition can only further restrict the access
control protections specified in the ACL since the file group
permission bits are used as a mask.

However, there must be a mechanism for reinstating the access
control protections that are stated in the ACL.

1.5  Recalculating the File Group Permission Bits

Several options were considered for recalculating the file group
permission bits.

1.5.1  Automatic_Recalculation

The initial proposal was to recalculate the file group permission
bits whenever a new ACL entry is added.  The following example
illustrates a problem with this approach.

   Consider a file created with a file creation mask of 0 in a
   directory that contained a fully populated default ACL.
   This file will have file group permission bits of 0, i.e.,
   --- yet may have named USER or GROUP entries specifically
   granting permissions.  (These entries will be effectively
   ignored during access checking because of the masking
   effect of the 0 file group permission bits.)  If the file
   group permission bits are automatically recalculated
   whenever a new ACL entry is added, the result of adding a
   USER entry specifically denying a user access will be to
   effectively grant access to the previously masked ACL
   entries.

It seems counter-intuitive at best to have the net effect of
adding an entry that denies a user access be the granting of
access to other users.  However, there does not exist a technique
to allow for the application of a single entry in an ACL and the
exclusion of others.

1.5.2  Other_Alternatives

Other proposed alternatives include providing a mechanism in the
"set_ACL" function to specifically request recalculation.  A
problem with this alternative is that it is not clear why one
would ever add an entry to an ACL if it wasn't the intent to have
it affect the access decision.  It isn't possible to have one new
named USER or GROUP entry be guaranteed effective in the access
algorithm without recalculating the file group permission bits
based on all entries.

1.6  Relationship of ACL and file permission bits

The file group class may be viewed as a mechanism for
implementing ACLs in a POSIX-conforming way that avoids conflicts
about alternate vs additional mechanisms.  ACL entries that are
not of the type USER_OBJ or OTHER_OBJ are considered to specify
additional members of the file group class, as permitted by the
definition of the file group class.

For an object without additional file group class members (i.e.
ACL entries), the file group class permission bits represent the
exact and only permissions of the entire file group class. When
an object has an extended ACL, the file group permission bits
represent the maximum permissions of the entire file group class.
Some members of the file group class permission bits (GROUP_OBJ
or additional ACL entries) may have fewer or more permissions
than are represented in the file group class permission bits
proper. However, permissions granted to a member of the file
group class will never be more than the permissions expressed in
the file group class (i.e. the file group permission bits act as
a 'mask' over the file group class entries).

When an ACL is placed on an object that previously had none, the
implementation must ensure that the previous permissions of the
GROUP_OBJ entry are preserved, unless they are specifically
changed in the ACL being set.

We note that the use of chmod on an object that has an ACL is a
use of an old mechanism in a new environment. There is no totally
satisfactory way to specify the resultant behavior. We believe we
should endeavor to support the intent of the chmod operation even
at the expense of losing the ACL flexibility and specificity.
Therefore a call to chmod must set the file group permission
bits. However, the chmod operation should not set the permission
bits of the GROUP_OBJ entry itself. This decision keeps the
following case from granting more access to the GROUP_OBJ group:

   group_obj permission bits = r--; file group class = rwx
   common programming sequence:
        permbits := stat(obj)   gets file group class bits of rwx
        chmod(obj,0)            temporarily disable access
        chmod(obj,permbits)     'restore' old state; don't want
                                group_obj to become rwx instead
                                of r--.


Volume-Number: Volume 17, Number 117