| |
| 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.) |
| |
| |
| |