You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Richard Hansen <rh...@bbn.com> on 2008/04/21 19:24:17 UTC
[CONTRIB] Re: [RFC] svn+ssh and authz: alternate method via a simple
setuid svnserve wrapper
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [CONTRIB] Re: [RFC] svn+ssh and authz: alternate method via a simple setuid svnserve wrapper
Posted by Karl Fogel <kf...@red-bean.com>.
Richard Hansen <rh...@bbn.com> writes:
>> Richard access to maintain it there (see
>> notes/commit-access-templates/partial-committer.tmpl), and then
>> Richard can make those changes under public version control.
>>
>> Richard, is this okay with you?
>
> That sounds great!
Great! See the template URL above and send the appropriate email to
svn.collab.net administrators, and we'll get you set up. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [CONTRIB] Re: [RFC] svn+ssh and authz: alternate method via
a simple setuid svnserve wrapper
Posted by Richard Hansen <rh...@bbn.com>.
Karl Fogel wrote:
> Daniel Shahaf <d....@daniel.shahaf.co.il> writes:
>> 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.)
>
> Richard volunteered to integrate it into Subversion's build system. So,
> I think the best course is: integrate it into contrib/, give Richard
> access to maintain it there (see
> notes/commit-access-templates/partial-committer.tmpl), and then Richard
> can make those changes under public version control.
>
> Richard, is this okay with you?
That sounds great!
Thanks,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [CONTRIB] Re: [RFC] svn+ssh and authz: alternate method via a simple setuid svnserve wrapper
Posted by Karl Fogel <kf...@red-bean.com>.
Daniel Shahaf <d....@daniel.shahaf.co.il> writes:
> 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.)
Richard volunteered to integrate it into Subversion's build system. So,
I think the best course is: integrate it into contrib/, give Richard
access to maintain it there (see
notes/commit-access-templates/partial-committer.tmpl), and then Richard
can make those changes under public version control.
Richard, is this okay with you? The copyright notice you have on it
already is fine for contrib/; it's essentially a MIT-style license,
customized for BBN, as far as I can tell. That'll work.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [CONTRIB] Re: [RFC] svn+ssh and authz: alternate method via a
simple setuid svnserve wrapper
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org