Here's an idea for how authentication/authorization could work, based
on discussions with Jim and others.

It completely avoids filesystem "property ACLs", and I believe that it
satisfies all the requirements in our alpha_checklist.

(written by Ben, 3/29/01)

-----------------------------------------------

Authentication
==============

If the repository is being accessed via http, then *any* existing Apache
method can be used to authenticate:  Apache's own passwd file,
certificates, kerberos, etc.

If the repository is being accessed via local disk, then the operating
system has already authenticated you.  Your identity is your UID.


Authorization
=============

Axiom: assume that the caller of the svn_fs.h interface has already
obtained a username somehow.  (In other words, authentication is not
the filesystem's problem.)

1. Add two new parameters to svn_fs_open_berkeley:

         svn_fs_open_berkeley (fs, env, username, auth_hook);

   Both the USERNAME and the AUTH_HOOK should be permanently stored in
   the caller's opaque fs object.

2. (Optional)  Write a new fs routine:

         svn_fs_change_user (fs, username);

    If, for some reason, the caller suddenly wants to operate on the
    fs as a different user, this will prevent the caller from having
    to "start over" (tossing the fs object and all derived root
    objects.)

3. In svn_fs.h, define an enumerated list of "actions", something like
   this:

       { 
         /* Create a new transaction */
         SVN_FS_ACTION_BEGIN_TXN,

         /* Read the contents of a node, either file text or dir entries */
         SVN_FS_ACTION_READ_CONTENT,

         /* Change a file's text */
         SVN_FS_ACTION_WRITE_CONTENT,

         /* Read the properties of a file or dir node */
         SVN_FS_ACTION_READ_PROPS,

         /* Write the properties of a file or dir node */
         SVN_FS_ACTION_WRITE_PROPS,

         /* Delete an entry from from a dir */
         SVN_FS_ACTION_DELETE_ENTRY,

         /* Add an entry to a dir */
         SVN_FS_ACTION_ADD_ENTRY
       }

     Of course, this is just an example.  This table could list any
     actions we want... presumably the actions would be sufficiently
     general to satisfy any authorization system.

4.  Modify the following svn_fs.h routines:

         svn_fs_begin_txn
         svn_fs_commit_txn
         svn_fs_abort_txn
         svn_fs_list_transactions
         svn_fs_node_prop
         svn_fs_node_proplist
         svn_fs_change_node_prop
         svn_fs_merge
         svn_fs_delete
         svn_fs_delete_tree
         svn_fs_dir_entries
         svn_fs_make_dir
         svn_fs_make_file
         svn_fs_rename
         svn_fs_copy
         svn_fs_file_contents
         svn_fs_apply_textdelta
         svn_fs_revision_proplist
         svn_fs_change_rev_prop

     These are all the routines that have something to do with reading
     or writing the fs.  (A routine like svn_fs_dir_delta is actually
     built on top of them, which is why it's not listed.)

     Each of the routines *must* begin by calling the AUTH_HOOK
     routine stashed in the fs object:
          
     /* Decide if USERNAME is allowed to perform ACTION on
        REVISION:PATH.  Return TRUE or FALSE.  */

           auth_hook (action, username, revision, path)

     Notice: all routines that "write" (and sometimes "reads") operate
     on transaction trees, not revision trees.  This means we'll need
     an internal mechanism that can map

           (txn_root, path) ==> (revision, path)

     This mechanism probably needs to be a table of some sort that
     lives *within* the txn_root object.  Every time the transaction
     is modified my svn_fs_copy, the table will need to be updated. 


5.  Write any old auth_hook you want:  

      * it might always return TRUE

      * it could authorize against an independent database full of users,
        groups, and roles

      * in the case of "local" repository access, we can still write
        an auth_hook that maps Unix UIDs to actions and fs paths.

        (In CVS, local access is determined by Unix file perms on the
        RCS files; a subversion repos can't function this way, since
        the db files are opaque -- it still needs an auth_hook.)