Richard Hansen wrote on Mon, 21 Apr 2008 at 15:24 -0400:
> 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.
Could any committer suggest whether the code can be placed in contrib/,
and (if the answer is 'yes') what else Richard needs to do to get to
that state?
(Quoted below is Richard's description of svnstsw.)
Daniel
> 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-27 13:40:11 CEST