On Wednesday 27 July 2011, Andy Canfield wrote: > I was trying to get http, svn, and svn+ssh to work.
Just one thing: Why? Why do you want more than one protocol? I could imagine read-only HTTP and read-write HTTPS, but that's the only reason for multiple access methods I could imagine. > Consider these commands: > * ssh k...@example.com > rm -rf /data/svn/subdoc* > They do nothing; user 'kids' has no right to see anything inside the > /data/svn directory, which is owned by www-data and readable (and > writable) only by that user. > > But consider these commands: > * mkdir t > cd t > svn checkout svn+ssh://example.com/data/svn/subdoc > svn delete * > ** svn commit* > These will post a revision deleting everything in the repository. Not true, they will create a new revision in the repository and that revision is empty. ;^) No need to check out for that either, you can pass URLs to "svn delete". No data loss either, all earlier revisions are still present and unchanged. I agree that such a revision is disturbing though, but not a fatal data loss. Anyhow, if you are using svn+ssh, you are only tunnelling the svn network protocol through an SSH connection. This is achieved by starting an svnserve process through SSH. svnserve itself will use direct file access to the repository. So, if you can do that and you can simply log in with a shell using SSH, then your security hole is that users have direct access to the files that make up a repository using an SSH shell. If, as you claim, users don't have file access to the repo via SSH, then you have some privilege escalation in between, probably using SUID executables. Summary: There is no security hole in SVN that you didn't drill yourself, either using the wrong permissions on the repository or using SUID executables. > And this second set of commands relies only on 'kids' being able to log > in to the server; they need not have any permission to do anything in > Subversion! The "permission [..] in Subversion" only exists in the actually used server like Apache or svnserve (even though the svnserve configs are stored in the repo folder). With the file access method, you need file-level access to the repo anyway, so any "permissions" could only be considered a suggestion anyway. > Is there any way to modify things on the server to disable the svn+ssh: > protocol without disabling either standard ssh or the svn: protocol? Disable the file-level access to the repository for users, only allow access to servers. If you need encryption, you could restrict access to using HTTPS or restrict access via svn to connections from localhost. In the latter case, users would have to SSH into the machine and work there or, better, create a tunnel. Uli ************************************************************************************** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at http://www.dominolaser.com ************************************************************************************** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **************************************************************************************
