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

Re: Should svnserve set umask to 002?

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-03-04 16:27:03 CET

On Thu, 2004-03-04 at 07:31, Nathan Sharp wrote:
> While I agree with you technically, practically I find the solution to
> be nothing more than a workaround and annoying, complicated by the
> fact that it has the side-effect that when using rav_local to check
> stuff out of the repository the created working directory has the
> bogus group write permissions set. The ideal solution would be to
> have options in DB_CONFIG which specifies a umask and group ownershipe
> to use just for the database.

We have some indication that BDB will eventually implement an option
like this. (It would probably be more like an API option to specify
that new logfiles should be chmodded to match the permissions of the DB
file.)

> Obviously that is out of your hands, but perhaps there could be a
> svn option which sets the umask while calling to the DB but leaves it
> at the original value when working with the working directory.

That wouldn't be thread-safe. (Welcome to Unix sucking.)

> Also, while the answer wasn't hard to find on the internet and in your
> book, it wasn't easy to discover either. A better error message would
> go a real long way here (and yes I know the error is coming from the
> DB, which you have little control over).

Yeah, I don't think we have a good way of distinguishing this error from
other errors.

We have talked about writing code to detect this condition either before
it happens (to prevent wedging the database) or after it happens (to
give a better error message when the database has been wedged this
way). The first option is a bit problematic because it might deny
access in some legitimate corner cases (e.g. I've made a private copy of
a repository and want to access it, and don't care that I will be
screwing up everyone else's access to my private copy), while the second
option merely requires violating the BDB abstraction barrier a little.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 4 16:30:21 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.