Effect of Masks When Editing ACLs

Here is the algorithm that the acl modify command uses when calculating the mask:

1. Retrieve the existing ACL of the file.

2. Perform all requests to remove entries and to reduce the permissions of existing entries.

3. Calculate the union of the actual permissions of all remaining entries.

4. Determine which permissions differ between the actual and effective rights. (This is the logical XOR of the results of steps 3 and 4.)

5. Perform all requests to add new entries to the ACL and all requests to increase the permissions of existing entries.

6. Calculate the union of these newly granted permissions and the old effective permissions (from step 4). This is the candidate 7.new mask value.

7. If there are any permissions in the candidate new mask that are also in the permissions that differ between the original actual and effective rights (from step 5), applying the candidate new mask would unexpectedly grant some new right that the user did not intend. Unless the user specified one of the options -mask calc, -mask nocalc, or -purge, this condition is an error, and the ACL is not modified. Otherwise, the candidate new mask is applied as the new mask.

For the vast majority of ACL operations, such automatic recalculation is safe. In certain rare cases, the recalculation of the mask can grant additional rights that the user did not expect; for instance, a permission granted to an entry that the user did not specify and that was not among the entry's previous effective rights.

The following example shows the way mask recalculation works, as well as the effect of the options.

Observe that the ACL contains an entry granting rwx permission to some user, but the mask allows an effective permission of r-x. Adding a new rwx ACL entry and recalculating the mask (according to step 6) to rwx is unsafe because the first user's effective access rights are unexpectedly changed from r-x to rwx. If the acl modify command detects such an unsafe condition, its default action is to issue an error message and not change the ACL.

The initial state, showing the permissions and the effective permissions, is

dcecp> acl show /.:/concertos

{user vivaldi rwx effective r-x}

{mask_obj r-x}

dcecp>

Adding a user as shown results in an error because the mask recalculation would give vivaldi an effective permission of rwx:

dcecp> acl modify /.:/concertos -add {user telemann rwx}

Error: Unintended permissions not granted.

dcecp>

Explicit use of the -mask calc option allows the recalculated mask to be applied in spite of the new permission granted to vivaldi. The mask is set to the union of the permissions granted to the file group class entries on the ACL. This option can result in the inadvertent granting of extra permissions.

dcecp> acl modify /.:/concertos -add {user telemann rwx} -mask calc

dcecp> acl show /.:/concertos

{user vivaldi rwx effective rwx}

{user telemann rwx effective rwx}

{mask_obj rwx}

dcecp>

Using the -mask nocalc option explicitly retains the r-x mask, resulting in reduced effective permissions for telemann. The ACL is modified exactly as specified by the user, and no mask calculation or purging of permissions occurs.

dcecp> acl modify /.:/concertos -add {user telemann rwx} -mask nocalc

dcecp> acl show /.:/concertos

{user vivaldi rwx effective r-x}

{user telemann rwx effective r-x}

{mask_obj r-x}

dcecp>

Using the -purge option replaces the actual permissions with the effective permissions in all entries. More precisely, if the command detects an unsafe condition, then the condition intersects the current value of the mask with all of the existing, unmodified entries in the file group class, replacing all ACL entries (except user_obj, other_obj, mask_obj and unauthenticated) with their effective permissions.

dcecp> acl modify /.:/concertos -add {user telemann rwx} -purge

dcecp> acl show /.:/concertos

{user vivaldi rwx effective r-x}

{user telemann rwx effective rwx}

{mask_obj rwx}

dcecp>