Hi all,
I have written a small svnserve wrapper (for POSIX systems) to enable
path-based access controls when using svn+ssh without doing the
authorized_keys trick. I want to contribute it, but before I do, I
would like to get some feedback. Specifically, I'm wondering whether
someone else has already solved this problem (a quick search of the
mailing list archives didn't turn up anything) and whether the general
approach I took has any significant flaws that I have not seen.
Background and motivation: Some of our projects require path-based
access control, but we don't want to use mod_dav_svn since we don't like
how the client caches the unencrypted password on disk. SSH with
ssh-agent makes us a bit happier, but this requires us to either make
the repository database files readable/writable to all users (thus
rendering the path-based access control meaningless) or have everyone
log in as a single 'svn' user via public keys and use the --tunnel-user
option in the authorized_keys 'command' option (as described in "SSH
configuration tricks" in chapter 6 of the svn book).
The authorized_keys trick works, but there are some drawbacks:
* Users must generate a public/private key pair. This can be a
non-trivial task for a novice user.
* The repository administrator must either manually maintain the
authorized_keys file (which makes it difficult for users to change their
keys or add a key from another machine) or set up an automated method to
add user-submitted public keys (which takes time).
* Users must log in to the server as user 'svn'. Unfortunately, bug
#2349 (http://subversion.tigris.org/issues/show_bug.cgi?id=2349) means
that users must either change the SVN_SSH environment variable, add an
entry to the [tunnels] section in ~/.subversion/config, or add a host
entry to ~/.ssh/config (assuming the '-r' option is used to specify the
path to the repository).
All of this adds up to a bit of support overhead that we would like to
avoid.
Our solution: In a nutshell, the wrapper execs "/path/to/svnserve -t
--tunnel-user=<user_that_executed_the_wrapper>". This wrapper is meant
to be installed with the setuid bit set and owned by the user who has
read/write access to the repository database files ('svn'). Thus, when
user 'foo' executes the wrapper, the wrapper runs "/path/to/svnserve -t
--tunnel-user=foo" as user 'svn'. Thus, user 'foo' does not need
read/write access to the repository files, making it harder to bypass
the path-based access controls. The wrapper uses the getlogin() and
getpwuid(getuid()) POSIX functions to fetch the username of the user
that started the wrapper.
What do you think? Does this sound like something the Subversion user
community would be interested in? If so, I'll post a link to the code
once it has gone through public release and a quick security review.
Thanks,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-07 18:28:37 CEST