[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

unix groups and umasks

From: Dirk van Deun <dvandeun_at_wilma.vub.ac.be>
Date: 2004-03-11 17:32:36 CET

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
Received on Thu Mar 11 17:32:59 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.