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

Re: svn+ssh umask and hangs

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-15 18:39:54 CEST

On Fri, 2004-10-15 at 09:59, Andy Whitcroft wrote:
> We see plenty of people who's repos' get wedged as a result of using
> svn+ssh and failing dismally to set their umask. This experience
> detracts from the perception of svn as it results in 'hangs' which need
> 'database recovery'. I am wondering how hard it would be to add some
> option to the repository to set the umask of the user?

About a year ago, I offered to implement an svnserve.conf option to set
the umask, but it would have raised some issues in threaded mode, and
people didn't like the idea of an access-method-dependent workaround.
See http://www.contactor.se/~dast/svn/archive-2003-11/1653.shtml for the

A more general solution is impossible because the umask is global
process state, and Subversion is implemented as a set of thread-safe
libraries. So we can't set the umask ourselves. We can chown files as
we create them, but these files are being created by BDB, which we have
no control over. (We've requested a BDB feature which would give us
more control over the modes of new DB files, and they've agreed in
principle, but the forthcoming BDB 4.3 release doesn't have that
feature, so I think they dropped us on the floor.)

In svn 1.2, FSFS may become the default back end. Until then, we're
stuck telling people that they have to explicitly use FSFS or meet the
BDB back end's stringent setup requirements.

> Perhaps defaulting to 002 for BDB repositories?

CVS bashes the umask to 002 by default, and I consider this a security
hole. If you're setting up a personal repository and expect your umask
to keep it private, you'll be surprised.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 18:40:23 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.