...

• Manage the authorized_keys file of a user account, and allow public key authentication for SSH.
• Configure commit emails for a repository.
• Manage access control for a repository.
• Manage integration of a repository with other MAP infrastructure such as Bamboo.
• Receive a partial or complete dump file of a repository.
• Post a dump file to be loaded into a repository.
• Automatically provision a new repository for an existing -users and -admin ownership group, to faciliate one project per repository.

...

• Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
• -admin groupsAdmin lists; 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 -users group will have access.By default, the admin list is the commiters group itself.

Security Model

Here is the security model to be used when phase 2 is complete:

• Each repository has an associated owner group containing the users allowed to commit to the repository.
• User shells are set to exec-svnserve, so they do not have unrestricted shell access.  (This is not a strong guarantee; they will be able to run arbitrary commands on the server as themselves via hook scripts if they have control of an appropriate local shell account.)
• User homedirs are set to /var/user/USERNAME.  Generally these directories will only contain SSH authorized_keys files.
• Some owner groups will contain local shell accounts which have regular shells.  Shell account homedirs are set to /var/shellacct/USERNAME.
• Owner groups will contain the svnserve and/or www users if they allow commits via svn:// or http://.
• Repositories will be owned by root and group-owned by the repository's owner group.
• Most of the directories and files in a repository will be owner-writable and group-readable.  The db and userhooks directories will be group-writable.
• The directories and files in a repository may be world-readable depending on user preference.  World readability will be required to allow anonymous read-only browsing if the group does not allow commits via svn:// or http://.
• Access via svn+ssh:// will be conducted by an svnserve process with the uid of the user.
• Access via svn:// will be conducted by an svnserve process with the uid of svnserve.
• Access via http:// will be conducted by an httpd process with the uid of www.
• The hooks directory will be populated with standard scripts of our own devising, which will be executed as the uid specified above.  It is important that users not be allowed to determine what actions these hook scripts take or they would be able to gain control of the svnserve and www accounts and thus write access to other users' repositories.  The behavior of these standard hook scripts will be controlled by configuration files in the repositories which can be edited by the administrator or (in phase 3) via the admin app.
• As their first or last action (not yet determined), each hook scripts will execute a subsidiary script in userhooks via a setuid wrapper which changes uid to the committing user.  These scripts can be user-determined via the owner group's local shell account if the owner group has one.

Since phase 1 does not include access via svn:// or http:// it will use a more relaxed security model where repositories are writable by their owner groups and can determine their own hook scripts.  Some repositories may be grandfathered into phase 2 with this model, but only if their owner groups do not allow access via svn:// or http://.

Inventory of Configurable State

User configuration

• What public keys are allowed for SSH access
• Whether the MAP password exists and what it is

Group configuration

• Whether commit access through DAV is possible for repositories owned by this group
• Whether commit access through the svnserve daemon is possible for repositories owned by this group
• What this group's admin list is (not user-configurable)
• What this group's shell account is, if any (not user-configurable)
• The namespace prefix for automatic provisioning of repositories, if any (not user-configurable)

Repository configuration

Some of these can only apply to a repository using the standard hook scripts. 

• Whether the repository is world-readable on the server (allows read-only DAV/svnserve access if commits through DAV/svnserve are disabled)
• The access control file for the repository
• Where commit emails for the repository go, if anywhere