On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield <andy.canfi...@pimco.mobi> wrote: > I was trying to get http, svn, and svn+ssh to work.
Dude. Pick one. Getting all three to play nicely together is destablilizing. > HERE IT IS USING HTTP: > svn info http://athol/svn/subdoc > Authentication realm: <http://athol:80> Athol Subversion Repository > Password for 'andy': > Path: subdoc > URL: http://athol/svn/subdoc > Repository Root: http://athol/svn/subdoc > Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 > Revision: 4 > Node Kind: directory > Last Changed Author: andy > Last Changed Rev: 4 > Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) Hold it right there. You're providing password based repository access via HTTP, not HTTPS? Please rethink this unless you *want* the passwords for this repository to be quite insecure and sniffable, especially if you're using normal user login passwords. Also note. For HTTP access from Linux and UNIX systems, the default behavior is to store the password, in cleartext, in $HOME/.subversioon/. *That* is a longstanding security issue that I've been ranting about for *years*. Subversion 1.6.x, very reasonably, now asks for permission before doing that, But if you're using the same password authenticatoin for svn+ssh://, http://, https://, and svn:// based access, you're now writing your password in plain text. locally. svn+ssh:// doesn't recored that plain text password, http:// and htps:// do. > HERE IT IS USING SVN: > svn info svn://athol/subdoc > Authentication realm: <svn://athol:3690> Subversion svnserve > Password for 'andy': > Path: subdoc > URL: svn://athol/subdoc > Repository Root: svn://athol/subdoc > Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 > Revision: 4 > Node Kind: directory > Last Changed Author: andy > Last Changed Rev: 4 > Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) Again. Unencrypted passwords, unless you're using something like SASL. Do not use this for normal user passwords. > HERE IS THE PROBLEM USING SVN+SSH: > svn info svn+ssh://athol/data/svn/subdoc > The authenticity of host 'athol (192.168.1.113)' can't be established. > ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7. > Are you sure you want to continue connecting (yes/no)? yes > kids@athol's password: > Path: subdoc > URL: svn+ssh://athol/data/svn/subdoc > Repository Root: svn+ssh://athol/data/svn/subdoc > Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138 > Revision: 4 > Node Kind: directory > Last Changed Author: andy > Last Changed Rev: 4 > Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011) > > What's 'worse' about it? Well, 'kids' is a valid user name on the server; Which it need not be. The gudebook does not make this clear enough: For users who have normal shell access *anyway*, many sites do use this approach and simply set the repository to be manged with group access to designated users. But in the "we don't want people to need shell access to use svn+ssh", you need to set up something like an SSH key on a shared account with forced commands, typically with this kind of URL. svn+ssh://svn@sitename/svn/reponame/ That "svn" user can be set to have no valid shell, with its shell set to something like "/sbin/nologin". This is actually quite common for system services to have no valid shell. This is how the "apache" or "www-data" user is usually set up. > 'kids' can ssh into the server. But 'kids' has no authorization to access > any Subversion repository in any way. To me this means that svn+ssh is a > GIGANTIC security hole. See above. That "forced command" bit is really important for systems where you don't want subverson authorized users to have shell access. I've actually had extensive battles about this sort of thing with sites where the internal policy was "as long as they're in, we already trust them with shell on such servers". This is actually tied to a subtler, longstanding deficit in Subversion: a dedicated shell for an "svn" user. I've attempted myself to integrate this sort of thing into the "rssh" toolkit used for rsync access. > 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. Only if you're using the "shared account" access method to svn+ssh, where the URL includes the username or otherwise successfully forces access to have that username. If you're doing the unfortunately common approach of normal user accounts with shared group access to the Subversion repository, you can scrub the database clean. It's one of the reasons I *hate* that normal user account method. The same sort of thing occurs in CVS repositories: it allows a considerable amount of relocation and behind the scenes editing of Subversion repositories, and is one of the ways to flush oversized binaries, such as DVD images, that soomeone might accidentally incorporate. It's also a way to *completely* screw up a repo for someone else, and one of the strongest reasons to have a backup system that uses 'svnsync' and talks to another location. Yeah. This is why you use a shared, SSH key accessed account without normal login shell access, but with for forced "commands" associated with the SSH keys. It's awkward and means you need key management, and it is untenable to use for single-sign-on tools such as Kerberos with GSSAPI. But it does seem to be *exactly* what Sourceforge uses, and has for years, for both CVS and Subversion repository access. Their git repository access can use the built in git shell tool more easily, and I'm sure it does. > 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. 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! First: that command won't do what you think. You'll wind up with t/subdoc, and the "svn delete" command will be in the "t" directory, and the "svn delete *" will be run from a non-subversion parent directory. But that's not the problem. The problem you're describing here is that in a normal, casually configured setup, it is *designed* to allow write access to the whole repository, and you can do something like any of these: svn delete http://athol/svn/subdoc/* svn delete svn://athol/subdoc/* svn delete svn+ssh://athol/data/svn/subdoc/* You don't need to check out anything to do moves and deletions, and this is normal. But all users in a casual setup have full access to delete *ANYTHING*, and to re-arrange it at whim. This is why the access control hooks are designed to allow people to say "OK, only the admins are allwed to write to trunk" or "only admins are allowed to write tags" or "anyone can create or flush branches, anyone can create tags, but no one can *delete* or move tags", and all the other options. > 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? Turn the question around. svn+ssh:// has to be *enabled* by providing the shared write access to the Subversion repositories. Simply keep the repositories owned with write permissions restricted to the designated "www-data" or "apache" user, and rely on the authentication to set the user for incoming connections, and there will be no enabled svn+ssh:// access. Frankly, I think people are a lot safer with the svn+ssh:// because of the password handling.