> This doesn't actually happen quite like that in Subversion, because the
> actual scenario is
>
> svn --> ssh --> svnserve --> Repository --> FileSystem
>
> That is, you use ssh for tunneling svnserve's socket connection, not for
> login onto the server. In fact, CVS does things like that, too.
>
> Of course, if you do allow users to log onto the server, whether via SSH
> or some other mechanism, neither SVN or CVS can do anything to protect
> your data.
I don't believe that svnserve uses sockets at all in this scenario - just
stdin/stdout. In which case it is pretty much as Pete so colourfully said,
you can have your way with the DB since the svnserve process is running as
the user and must be given read/write on the repo.
Actually tunneling the socket is the method I use. It's a two step process
and one not talked about in the book or the FAQ. First you create an ssh
tunnel to the svn server, then you access the repo via "localhost". It has
the advantage that your svn users don't need to have perms on the DB repo
files. And for the really paranoid, you can restrict the svnserve process
to only accept connections from localhost, thus the only exposure needed is
ssh.
I hope I'm right, 'cause that's the way I'm running it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 29 03:41:12 2004