Phase 1: SVN 1.4 upgrade

This phase will focus on ironing out the details of the IPS-to-OIS rollout process.  The test server map-dev-svn1 will be set up to duplicate the features and user management of the existing svn.mit.edu service, with an upgrade to SVN 1.4.x being the only new user-visible feature.  The new service will be rolled out to OIS and existing repositories migrated.  svn.mit.edu will become separate from cvs.mit.edu at this time.

Phase 2: DAV, ra_svn, MAP passwords, possibly SVN 1.5

An IPS standard Apache HTTPD 2.x installation will be added to map-dev-svn1. The SVN server will be rebuilt with support for DAV (http(smile) and ra_svn (svn: without the SSH tunneling).  DAV access will support authentication with Kerberos, MIT certificates, and passwords over SSL.  ra_svn access will support authentication with passwords and possibly Kerberos.  Both access methods will also support anonymous read-only access if repositories are appropriately configured.

If Subversion 1.5 has been released by the time this phase gets underway, it will be used for this phase.  Subversion 1.5 is a requirement for Kerberos ra_svn authentication.

A new administrative web application, itself a MAP project running under Tomcat (probably without SASHServer), will be developed for this phase.  Initially the only feature of this application will be the provisioning of MAP passwords.  Users will authenticate to the application with certificates (or Touchstone if that's an option at this point in time) and will have the option to create, destroy, display, or change their MAP passwords.  Users do not get to choose MAP passwords; they are randomly assigned.  MAP passwords are only recommended when stronger authentication is not an option.  The web application will store a master list of MAP passwords, and a script will propagate the passwords to the /etc/shadow file (for SSH authentication) and to the svnserve and HTTPD password files.  MAP passwords eventually be reused when appropriate for other pieces of MAP infrastructure running on src.mit.edu and build.mit.edu, such as Bamboo.

Phase 3: Expanded administrative features

The administrative application will be extended to support new features, which can be rolled out one at a time.  Likely features include:

  • 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 ownership group, to faciliate one project per repository.

In parallel with the above, the following new user management features will be implemented:

  • Support for users without Kerberos principals.  Touchstone and CAMS are prerequisites for this.
  • Admin lists; these are subsets of committers groups and control who has access to manage a repository through the web application. 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
  • No labels