Basic ACL semantics

[Alexey M. <al...@hs...>]

This message is a conclusion to a discussion that happened in private
during the initial testing deployment.


In short, I believe that we have missed an important case regarding
the distinction between the "directory has an associated Access
Control List" and "directory does not have an associated Access
Control List".  This concept, being supplemented with an idea of
"repository policy", gives an answer to all the incoherency reports
that we have seen.


Below is an appropriate new chapter in acl-rfc.txt.  It also gives the
detailed sequence of steps we take when calculating the directory
permissions.  I shall implement that, and then we'll reconsider the
code in NCLI-1-11-1-NEWACL branch. 



======================================================================


Basic Semantics
================

The ACLs for a particular directory or a file are generated traversing
from the "top-level directory", i.e., repository directory, towards
the particular directory or a file.

The basic semantics is restrictive-only.  You cannot give additional
rights to user in a directory, if parent directory prohibits those
rights.  E.g., if the module directory grants only "access" rights to
user, she could not in any way get a "modify" or "checkin" rights in
that module.


We must strictly differentiate between two cases:

 - the directory itself does not have an associated Access Control
   List (i.e., there is no file DIRACL in that directory, or it is
   empty: this is rather common case);

 - the directory has an associated Acess Control List.


Repository policy
------------------

"Repository policy" is an "allow"/"deny" decision which is used when
there were no associated ACLs in all of the directories along the
particular path.  Repository policy is controlled by the
`CVSROOT/default-deny' file:

  - if this file exists (its contents is ignored), the repository
    policy is "deny";

  - if this file does not exist, the repository policy is "allow".


Directory permissions semantics
--------------------------------

Here is how the permissions are checked for the particular directory:

- we set the current effective permissions to 'all';

- for each of the the parent directories down from the top-level
  directory:

   - if the parent directory does not have an ACL, it is skipped;


   - if the parent directory has an ACL, we AND-mask the current
     effective permissions with the permissions we get for that parent
     directory;

     [ E.g., those permissions could still be "all", or become
       "access", or become completely restrictive, "none".

       Note that there is no way for the effective permissions to
       become less restrictive while traversing the list of [parent
       directories. ]

- if none of the parent directories did have an associated ACL (i.e.,
  this could happen in a pre-ACL repository), we look at an ACL for
  the target directory.   Again, there are two cases: either the
  target directory has an associated ACL, or it doesn't have one.

  So, we have four cases: 

  - parent directories did not have ACLs; target directory does not
    have ACL:

      we check the requested permissions against the repository
      policy;

  - parent directories did not have ACLs; target directory does have
    ACL:

      we check the requested permissions against the target directory
      ACL;

  - parent directories did have ACLs; target directory does not have
    ACL:

      we check the requested permissions agains combined permissions
      of parent directories;

  - parent directories did have ACLs; target directory does have ACL:

      we check the requested permissions agains combined permissions
      of parent directories combined with permissions of target
      directory;


That's all.


--alexm