Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 3 down vote accepted

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.

share|improve this answer

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/

share|improve this answer

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.

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.