[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: Sigfred Håversen <bsdlist_at_mumak.com>
Date: 2004-10-15 19:19:06 CEST

On Friday 15 October 2004 18.39, Greg Hudson wrote:
> 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
> thread.
> 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.

With a SSL layer to svnserve this problem would disappear as a deamon running
under it's own unique user/group id would take care of this.

As it happens, I'm working on a patch to introduce this layer (using
"capabilities"). It passes "make check", but client certificate
administration has yet to be implemented. I suppose using ra_dav for https as
model will be sufficient.


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