The aforementioned svnserve wrapper (with the unimaginative and
unpronounceable name 'svnstsw') is now available at:
http://www.ir.bbn.com/~rhansen/svnstsw/
My short-term goal is to get this code to a state where it can be placed
in the contrib/server-side directory. The code comes with its own
independent autoconf/automake-based build system, but I would be happy
to integrate it with Subversion's build system if someone could provide
me with a little guidance.
=======================================================================
About svnstsw:
svnstsw runs Subversion's svnserve program in tunnel mode, setting the
tunnel username equal to the username of the user that invoked svnstsw.
Using this wrapper, repository administrators can have meaningful
path-based access controls when using the svn+ssh access scheme without
resorting to the authorized_keys trick. Normally, the svn+ssh scheme
requires the repository administrator to make all repository files fully
readable and writeable by all users. Unfortunately, this configuration
allows users to easily bypass svnserve's access controls. With svnstsw
installed and the setuid or setgid bit set, repository administrators
can take direct filesystem access away from users and prevent them from
bypassing svnserve's access controls.
This wrapper works by exec()ing svnserve with the --tunnel and
--tunnel-user=user arguments, where 'user' is the username of the user
that invoked svnstsw (as determined using either getlogin_r() or
getpwuid_r() with getuid()).
This wrapper was written for Subversion 1.4.
=======================================================================
-Richard
Richard Hansen wrote:
> 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-22 08:31:05 CEST