You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Andy Whitcroft <ap...@shadowen.org> on 2004/10/15 13:59:54 UTC
svn+ssh umask and hangs
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? Perhaps
defaulting to 002 for BDB repositories?
-apw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn+ssh umask and hangs
Posted by Sigfred Håversen <bs...@mumak.com>.
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.
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn+ssh umask and hangs
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org