9

I use snv+ssh with key based authentication. Right now in order for any of my svn users to access the repository through Subversion, I must set the repo files to be readable and writable on the filesystem to those users.

I want to prevent the users from being able to delete the repo database when logged in to the server via ssh, yet stil be able to checkout and commit code.

Thoughts on how I can do this?

5 Answers 5

4

To access an svn+ssh URL the svn client launches an svnserve instance using "ssh -q user@host svnserve -t" and talks with that instance through stdin/stdout.

If your users need normal ssh access you can still prevent them from accessing the repository by limiting access to one user (chown -R svnserve:svnserve repo; chmod -R g-rwx,o-rwx repo) and by replacing the svnserve command by this setuid/setgid svnserve wrapper program.

10

In a shared user environment, I would recommend setting up a real Subversion server (either svnserve or through Apache). In this environment, individual users do not need access to the repository files at all because all file access is done under the user account of the server process.

The Subversion book has a section on Choosing a Server Configuration which may help. From that section (emphasis mine):

If you have an existing infrastructure that is heavily based on SSH accounts, and if your users already have system accounts on your server machine, it makes sense to deploy an svnserve-over-SSH solution. Otherwise, we don't widely recommend this option to the public. It's generally considered safer to have your users access the repository via (imaginary) accounts managed by svnserve or Apache, rather than by full-blown system accounts.

4

This site has some nice tricks: http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

If none of that works for you, maybe a workaround could do the trick? You can take a backup of the repository each time someone commits something by adding something like this to the commit hooks: sudo rsync -a /my/repo/path /my/closed/path/

2

I see two possible directions to attack this problem:

  • provide limited shell access, e.g. the users can only use svn with their accounts (may need another account if shell access is also required for other purposes) - I've found a few interesting references googling for svnonly. Note: didn't try them myself.
  • migrate to subversion over https, adding client certificates. I've seen people discussing this, but never did it myself. Downside: requires distribution of client certificates in addition to the ssh keys.
1

i concur with Greg and Olaf - go for https access. i'm using such a setup for quite some time and dont see really any downside of it.

you'll get additional benefit of fine-grained access control within repository - so you can make some parts of it read-only and some completely inaccessible for selected users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .