...

• Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
• -admin groups; these are subsets of -users committers groups and control who has access to manage a repository through the web application. If an -admin groups does not exist, all members of the -committers group will have access.

Issue: Security architecture and hook scripts

The current svn.mit.edu service uses ssh tunneling to run svnserve as a different uid for each svn user.  Group ownership is used to restrict read and write access by these svnserve processes.  Several projects have corresponding "snap" accounts which are allowed to create arbitrary hook scripts for a repository.  Hook scripts are executed as the committing user, so a hook script created by one user cannot gain access to a second user's repository.

As we add DAV and ra_svn access, we will not be able to trivially preserve this security model.  With DAV access, repository manipulations are done with the uid and gid of the web server process; with ra_svn access, with the uid and gid of the svnserve network daemon.  Hook scripts are also run with these identities.

To make commits work via these daemons, the web server or svnserve uid will need to be added to the repository's -committers group.  (Thus, commit access via daemons can be disabled by omitting the relevant uid from the -commiters group.)  For read-only access via daemons, either the relevant uid needs to be in the repository's -

...

commiters group or the repository needs to be world-readable on the server.

Since all hook scripts will be run with a single UID and that UID will have write access to many repositories, we are limited to several options for the hook script security model:

1. Do not allow custom hook scripts for repositories accessible by the daemons--no "snap" accounts with write access to the hooks directories of such repositories.
2. Develop machinery to make custom hook scripts execute as the committing user.
3. Accept a weak security model where users can gain access to other user's repositories with enough effort.
   The third option is probably not acceptable to us, particularly after we add support for non-Kerberos users, but it's worth noting that web hosting has a similar security issue and most web hosting providers have taken the third approach.