On 7/28/2011 9:29 AM, Andy Canfield 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.
Hardware is cheap. More than one OS distribution with a working,
packaged subversion is free. Why are you fighting with something that
doesn't work? I'd be very surprised if you really can't run mod_dav_svn
on OSX, though. Worst case should be that you grab the apache source
and recompile the whole thing together to make sure the modules match.
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."
Yes, that is pretty common for private use. And the stock apache setup
for a linux distribution may already include this.
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.
It starts its own svnserve as that user. If you don't want them to have
access at all, use filesystem settings to block them (i.e. don't put
them in the group that has access). Beyond that, use an authz file.
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".
That suggestion was for using a shared login for svn. If you don't want
shared logins you could create new individual logins just for use with
svn. Given your borked OS, that might be the quick fix for you. Add
user_svn logins for each user that should have svn access, make keys for
them but don't give out the passwords. Then restrict the ssh command
that can be issued with those keys. A little extra setup work but
nothing complicated.
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
Note that this does not delete anything that already exists in the
repository - which is a large part of why you use revision control. It
will make a new head revision where the things the client deleted do not
appear. You can still check out or update to the earlier revision where
it does exist. And you can view the logs to see who did it and when.
The thing you really need to protect against is filesystem write access
to delete or scramble the server's copy of the repository files - and
you should have a fairly up to date backup on a more restricted system
in any case.
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.
They are running under their own uid. If that uid can't write to the
repository files, they can't modify anything. But, didn't you say
something about making svnserve setuid a while back? That would break
things.
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.
Having _any_ write access comes from filesystem permissions. Making it
more granular needs an authz file.
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?
Make your apache force a redirect to port 443 if a user attempts to
connect to port 80 in that location. Apache is infinitely configurable.
If 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?
Don't give that account write permission on the repo files or the
directories above. This isn't particularly unique to subversion.
--
Les Mikesell
lesmikes...@gmail.com
