On 07/27/2011 06:47 PM, Nico Kadel-Garcia wrote:
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.
For me, getting any of the four to work is difficult. Here is the status
of the various protocols, in order by apparent desirability. The
problems are in parentheses.
Server: Test Production
Network: on LAN on Internet
-------- -------------------
1. HTTPS: (config) (config)
2. HTTP: OK (software mismatch)
3. SVN: OK (port not forwarded)
4. SVN+SSH: (security) (security)
Now you see why I'm trying to get any of them working. Every alternative
has a problem. I can't get HTTPS to work at all. HTTP on the production
server fails due to a software mismatch which we may not be able to fix;
the distro from Apple seems to be bad. SVN requires our ISP to change
our Router settings. SVN+SSH authentication worksfor me without
authorization checking.
HERE IT IS USING HTTP:
   svn infohttp://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.
If HTTP sends passwords in as plain text then yes, HTTPS is better. But
I can't get HTTPS to work at all. I get the impression from googling
that HTTPS requires a certificate, and I don't have a certificate. If I
could generate my own certificate, we could tell our developers "Accept
this certificate the first time you see it, and after that it will work
every time."
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.
Unencrypted passwords stored on the server. We can make the file
accessable only by the Apache user. Not ideal, but not bad. If the
hacker roots the server we've got no security anyway.
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/
Near as I can tell svn+ssh uses ssh for authentication but it does not
seem to do any authorization at all. At that point anybody with an SSH
login can do anything; there is no authorization phase for svn+ssh. I am
trying to fix that, perhaps using an authz file in every repository, but
haven't got it working yet.
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.
But that would prevent login using ssh, which I don't want. I can tell
the sysadmin "we need an SSH login for Charlie so he can use
Subversion", but I cannot say "You have to cut the SSH login for Marilyn
so she can't use Subversion".
'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.
I am working on a changed arrangement, where the SVNParentPath is
"/Subversion" and in this is a subdirectory named "conf". Inside config
are files "server.conf", "passwd", "htpasswd", and "authz". These files
are used for authentication whenever Subversion needs to do it; they
should be used for authrization in all cases. Then
/Subversion/repository/conf is a symoblic link to /Subversion/conf.
Maybe it will work; maybe not.
Consider these commands:
   sshk...@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.
I think it does do what I think it does.
<== The current directory is /a/b/c
mkdir t <== create /a/b/c/t
cd t <== The current directory is /a/b/c/t
svn checkout svn+ssh://example.com/data/svn/subdoc <== /a/b/c/t is
a working copy
svn delete * <== delete everything in this working copy on next commit
svn commit <== New revision, deletes everything
I might also do:
cd .. <== The current directory is now /a/b/c
rm -rf t <== wipe out my working copy in t
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 deletehttp://athol/svn/subdoc/*
svn delete svn://athol/subdoc/*
svn delete svn+ssh://athol/data/svn/subdoc/*
http: requires Apache authentication and uses dav_mod_svn authentication
and authorization . svn: uses the svnserve daemon which was run with a
"--config-file=..." parameter for authentication and authorization.
svn+ssh uses SSL for authentication but because SSL is running a fresh
copy of svnserve we have no chance to tell svnserve where to look for
the authorizations.
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.
But users that Subversion has never heard of should not have that power.
My testing of svn+ssh indicates that once ssh authenticates a user,
svnserve does not seem to check authorization at all. That's my problem.
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.
I can get authentication but cannot yet get suthorization.
So there are actually four protocols that a workstation can use to
access a Subversion repository: http, https, svn:, and svn+ssh. Assuming
that I pick one, how do I turn the others off? If James Bond can access
via https, how can we prevent him from using http and blowing the
security? iIf James Bond has an ssh login account on the server, but
should not be using Subversion at all, how do we prevent him from using
svn+ssh:? How do we prevent him from logging in and using file:? How do
we prevent him from logging in and running svnadmin?
