emax

Now that we can log in automatically (SVN Part 1), we can do some cool stuff. This summer I managed a SVN server for a company that has multiple programs, each of which had different developers working on them. Each of these programs is stored as a repository in SVN. For example, developer A needs access to repository 1 and 2 and developer B needs access to repository 1 and 3, etc. To make it even trickier, in repository 1, developer A should have access to the entire repository, while developer B should only have access to the directory devB in repository 1. Also, every time a developer makes a change to a file, the change needs to be logged with their username.

This is where the RSA keys come in. Each repository should be owned by a different user. For example, /usr/bin/svnserver/repository1 is owned by user repo1, /usr/bin/svnserver/repository2 by repo2, etc. Put any developer who needs access to [repo]‘s RSA pubkey in the /home/[repo]/.ssh/authorized_keys file, where [repo] is the name of the repository’s owner (repo1, repo2). Configure authorized_keys like:

command="/usr/bin/svnserve -t -r /var/svn/ --tunnel-user=[developer's username]",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-rsa [developer's RSA pubkey]== [developer's username]

This enables developers to check out [repository] using: svn+ssh://[repo]@[server]/[repository]. While we are sending the information over SSH, the developer does not have a SSH account and can do nothing but use SVN to check out (svn co) and update (svn ci) repositories owned by a user (repo1, repo2) whose authorized_keys file contains the developer’s pubkey. The last column in the authorized_keys file is the comment line. SVN automatically uses this line as the comment when a developer commits code to the SVN repository.

The last part, giving only partial access to a repository, coming in Part 3.

Max Sobell backup, code, linux, software