You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Perry E. Metzger" <pe...@piermont.com> on 2004/02/13 22:56:38 UTC

problems with sgid "svnserve"

>> I created an svn group, made svnserve setgid "svn", and made the
>> repository db and locks directories and files writable by group
>> "svn". (It is nowhere documented what portions of the repository need
>> to be writable -- that's unfortunate.)
[...]
> Actually, this seems to be not entirely the case -- I'm having trouble
> with post-commit scripts. In particular, my commit mail script is not
> running sgid svn.

So it appears that, on linux (where I was running my tests), if the
shell is executed and the effective gid != the real gid, the shell (or
perhaps the kernel, I haven't looked at the source) sets the effective
gid to the real gid first. This does not appear to happen for other
interpreters. Perhaps someone who knows more about linux than me can
explain why -- I'm a poor BSDhead.

To get around this, I temporarily changed post-commit to a perl script
that sets the real gid to the effective gid and executes the real
script. Doubtless this provides for a bit of a security hole in that
one could play games the with the shell's file descriptors etc. --
doubtless the reason for the "protection" in the behavior -- but for
the moment, this has hacked around the issue for me.

Probably the right thing to do is to put some support into svnserve
for running the hooks in a sgid environment safely. Given that, the
rest of the stuff will just work right.


-- 
Perry E. Metzger		perry@piermont.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: problems with sgid "svnserve"

Posted by "Perry E. Metzger" <pe...@piermont.com>.
"Perry E. Metzger" <pe...@piermont.com> writes:
> So it appears that, on linux (where I was running my tests), if the
> shell is executed and the effective gid != the real gid, the shell (or
> perhaps the kernel, I haven't looked at the source) sets the effective
> gid to the real gid first.

It is bash, being "helpful". I hadn't encountered this ever before
because I rarely use linux, and on most other systems /bin/sh is not
bash.

I've considered a number of solutions -- for now, the best of the bad
alternatives I seem to have is this c program, which I'm running as a
wrapper around "svnserve". I set it setuid root, setgid whatever group
I want the repository to be, and all is well, after a fashion.

I think something like this probably should be included with
subversion in the future, for the benefit of people who want to run
with a setgid svnserve and a repository set writable only to that
gid. Having svnserve itself be setuid root seems like a bad idea --
this program is small enough that it is probably safe.

----------------------------------------------------------------------
/*
 * Wrapper to run the svnserve process setgid.
 * The idea is to avoid the problem that some interpreters like bash
 * invoked by svnserve in hook scripts will reset the effective gid to
 * the real gid, nuking the effect of an ordinary setgid svnserve binary.
 * Sadly, to set the real gid portably, you need to be root, if only
 * for a moment.
 * Also smashes the environment to something known, so that games
 * can't be played to try to break the security of the hook scripts,
 * by setting IFS, PATH, and similar means.
 */
/*
 * Written by Perry Metzger, and placed into the public domain.
 */

#include <stdio.h>
#include <unistd.h>

#define REAL_PATH "/usr/bin/svnserve.real"

char *newenv[] = { "PATH=/bin:/usr/bin", "SHELL=/bin/sh", NULL };

int
main(int argc, char **argv)
{
	if (setgid(getegid()) == -1) {
		perror("setgid(getegid())");
		return 1;
	}

	if (seteuid(getuid()) == -1) {
		perror("seteuid(getuid())");
		return 1;
	}

	execve(REAL_PATH, argv, newenv);
	perror("attempting to exec " REAL_PATH " failed");
	return 1;
}
----------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org