unix groups and umasks

[Dirk van Deun <dv...@wilma.vub.ac.be>]

I have been trying to use a wrapper to make svnserve do exactly The
Right Thing when called via svn+ssh.  The Right Thing would be
figuring out what repository is being accessed, setting the right
umask and the right unix group, and calling the real svnserve.

The problem is that the wrapper script has no means of finding out
what repository is being accessed, only which user is logging in
(with a simple "id").  All projects have their own unix groups,
which need to be newgrp'ed to in case a file will be created during 
the repository access.  Using some heuristics I could write a
wrapper for a specific situation, because I know which user is
involved in which project, and at my site it happens that users are
involved in at most one project.  But this is dirty hacking.

Might I propose that svnserve behave a bit more intelligently when
called via svn+ssh, specifically that (on unix-like systems):

  - the svnserve process match its own umask to the (inverse of
    the) rwx permissions of the root directory of the repository;
  - the svnserve process (try to) match its group id to the 
    owner group of the root directory of the repository.

This would make svn+ssh practicable for more than single-user
projects.  Creating an ad hoc additional unix group to give a subset
of "users" access to a project is a time-honoured technique.  It
would be nice if svnserve honoured it too.

As it is, you have to either jump through too many hoops (if it is
at all possible), or use a listening server process or apache.

Dirk van Deun
--
Licensed to (kill -9)

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

Re: unix groups and umasks

[Ben Reser <be...@reser.org>]

On Thu, Mar 11, 2004 at 07:26:30PM +0100, Dirk van Deun wrote:
> Well, 007 for group projects and 077 for personal projects ideally, but
> this is indeed not crucial.  Umask 007 will do for everyone, as the
> project root of personal stuff can still be chmod'ed to 700.

If your users have their own group (which a lot of Linux distros now do
for you when you add a user, not sure what OS you're using), then you
can just set the group on the repo to the users group for personal
projects.  Then 077 would be fine on both.

-- 
Ben Reser <be...@reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

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

Re: unix groups and umasks

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2004-03-11 at 11:32, Dirk van Deun wrote:
> The problem is that the wrapper script has no means of finding out
> what repository is being accessed, only which user is logging in
> (with a simple "id").

Normally, people in this situation can get by with the same umask
directive for all repositories.

> All projects have their own unix groups,
> which need to be newgrp'ed to in case a file will be created during 
> the repository access.

If you set the repository directories to have the g+s bit, then new
files will be created with a group ownership of the directory's group
owner, rather than by the user's primary gid.  (On some operating
systems, I think particularly the *BSDs, this behavior holds even
without the g+s bit, and the g+s bit on a directory is a no-op.)

This should remove the need for any process gid hacking.

> Might I propose that svnserve behave a bit more intelligently when
> called via svn+ssh, specifically that (on unix-like systems):
> 
>   - the svnserve process match its own umask to the (inverse of
>     the) rwx permissions of the root directory of the repository;

I've offered to make svnserve set its umask based on repository
configuration in svnserve.conf; I hadn't thought about intuiting it
based on the existing DB files.  At any rate, the rest of the
development community wasn't wild about a umask solution which is
specific to one particular access method.

We expect some future BDB version to give us relief on the umask issue
by providing an option to chmod newly-created logfiles to match the mode
of the DB files, but we don't know when that will come out.

>   - the svnserve process (try to) match its group id to the 
>     owner group of the root directory of the repository.

I think this would require shelling out to /usr/bin/newgrp when not run
as root; given the more elegant g+s bit solution, I don't think this
would be appropriate.


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