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