On Fri, Sep 05, 2003 at 11:42:59PM +0200, Tobias Ringstr?m wrote:
> e.huelsmann@gmx.net wrote:
> >Tobias,
> >
> >I'm a nobody too. We were definitely not discussion messing with
> >permissions. We were discussing where and how to throw an understandable
> >error message
> >or to leave it to berkeley to display any error (not permission denied
> >btw).
> >
> >Greg Hudson, Mark and I advocated checking conditions so as to be sure that
> >if any db errors occur, that they are not due to inaccessability of the
> >database by berkeley. John said "there's nothing wrong with BDB and
> >nothing with
> >our use of it, so we should do nothing. It's the users fault". (Ofcourse
> >this
> >is what I understood their comments to be.)
> >
> >So I think we agree to the solution we are currently persuing?
>
> OK, I've tried to read up on the whole conversation. I'm tired and
> stupid so I may have misuderstood it all, but here goes nothing:
>
> The current code will print a "permission denied" error message if BDB
> fails because of a permission problem. When this happens, the admin must
> fix the problem by hand. There will not be any confusion because the
> error message is clear. It it not clear enough, it would be a fiveliner
> to add an URL to the FAQ in the error message.
>
> The holy grail would of course be to prevent a user with a bad umask
> (for example) to wedge the repos for all the other users. Doing so would
> definately involve messing with permissions, and it would be hard to get
> it right, IMHO.
>
> Is it possible that you are trying to solve an old problem? Just a short
> time ago neither ra_dav, ra_svn nor ra_local did manage to present a
> "permission denied" error message to the user, but now they do.
>
> So I'm just wondering if this is still a problem? Do you have an example
> where you get a different error than "permission denied" when it really
> is a perssion problem?
>
> /Tobias, nobody, tired and stupid :-)
As far as I can tell, there isn't a way we can perform an a priori
check on permissions and determine whether or a given user's access
will trash the repository.
What has been suggested is to check that the umask is either 0002 or
that the owner of the directory is the same as the user who is about
to create files in that directory.
However, it is valid for svn.svn (group writable) to own a directory
and for bob.svn to write files to the repository with a 0022 mask as
long bob is the only user using the repository.
Perhaps you are right that the existing 'permission denied' message is
sufficient. I wonder, though, that users are still confused that it
means that their repository permissions are inconsistent.
The tack I've been angling is to check that the user accessing the
repository will have sufficient priviledge to access it. There is
another angle, though, which is a bit more aggressive. We could check
that a file written by the current user would be accessible to others
who have written log files. This can be done without violating the
BDB abstraction since we can enumerate log files using a BDB call.
Using this kind of check, we can block some types of repository access
that would corrupt the DB. It wouldn't be foolproof, but it would be
a) inexpensive, and b) never a false negative...I think.
What about that?
Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 6 04:56:12 2003