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

Re: Could svn check permissions?

From: Marc Singer <elf_at_buici.com>
Date: 2003-09-05 21:28:49 CEST

On Fri, Sep 05, 2003 at 02:52:21PM -0400, Greg Hudson wrote:
> On Fri, 2003-09-05 at 13:32, John Peacock wrote:
> > > We cannot set the group permissions of a BDB database without looking
> > > under the covers.
>
> > Isn't it possible to use setgid() to change the group ID of the current process
> > only (in this case the svnadmin)?
>
> I guess that might work. (For Unix only, of course, and probably only
> for repositories created by root.) I'm not sure whether it's worth
> adding a flag; anyone who knows to use the flag is probably just as
> capable of running chgrp -R after running svnadmin create.

I'd say that this is a bad idea, too. It isn't really for us to say
how a user is to set permissions since there are many legal
configurations.

> > > libsvn_fs is a library. It cannot in good conscience modify global
> > > process state. (We can't even get away with modifying it and setting it
> > > back again when we're done, because of threads.)
> >
> > While it is true that libsvn_fs is a library, it is a mediating library, by
> > which I mean that no access to the database happens except through that library,
>
> Correct, but...
>
> > Since all roads lead through
> > libsvn_fs, there are no thread issues per se since every thread will set the
> > same umask settings before opening the database.
>
> The danger is that the bashed umask might be erroneously applied to
> other operations besides Berkeley DB operations.
>
> Also, we wouldn't want to bash the umask in all cases; the user might
> actually want a private repository. Determining when it's appropriate
> to bash the umask might require violating the BDB abstraction layer.

It isn't valid for us to set umask except with explicit permission
from the user. We could add some switches which would obviate the
need for a wrapper. Then again, why bother?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 5 21:29:36 2003

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.