On Fri, Sep 05, 2003 at 02:43:36PM -0400, Greg Hudson wrote:
> On Fri, 2003-09-05 at 14:38, Marc Singer wrote:
> > > (1) The user has full access to the repository, but is not the same as
> > > the owner of the repository, and has a umask of 022 or worse. So
> > > accessing the repository would work fine, but would break things for the
> > > next person to come along. (We can't just reset the umask because we're
> > > a library and we can't muck with global process state like that, and we
> > > can't munge the permissions of newly-created logfiles because Berkeley
> > > DB has no support for that.) We would like to preemptively error out in
> > > this case to avoid putting repositories into inconsistent states.
> >
> > I think that we can ignore this problem. Before yelling... If a user
> > does this, then it isn't really our problem.
>
> It absolutely is our problem. It comes up on the list all the time.
> Anything users do frequently, even if it's something wrong, is something
> we have to handle gracefully if at all possible. (That can mean
> succeeding, or failing with a helpful error message.)
We have two responsibilities:
1) prevent data loss
2) be clear with error messages
IMHO, the problem with the troubles seen by users is that their
repositories become corrupt without being told why. *AND* we can be
more clear.
Without mandating a setup, there will always ways that users can make
their repository non-functional. As long as we can tell them why, I
think we can finesse some situations that create the problem.
> > Moreover, we don't know if a user has
> > configured a private repository that can only be accessed by a single
> > local user. A umask of 077 could be valid.
>
> Yes, but I specifically wrote "... but is not the same as the owner of
> the repository..." to address that case.
>
> > > (2) The user does not have required access to the repository, perhaps
> > > because of something like what I described in (1). We would like to
> > > preemptively error out in this case so that people realize they have a
> > > permissions problem and not a data corruption problem.
> >
> > Right. If we catch this case, then we handle 1) because someone will
> > later experience a well-worded error that explains the situation.
>
> But they may not be in a position to fix it, whereas the user in (1) is
> in a position to prevent it from occurring in the first place.
I see what you mean. This is the case where any files created by the
ambient user will not be accessible by the user who created other
files. This may be a tricky one to enforce since it may be hard to
sus the user's intent without making some unacceptable inferences
about the BDB layout. For example, it is possible that the directory
is owned by svn.svn group writable, and the log files are all owned by
bob.svn umask 077, and that bob owns the whole repository. The SVN
user can administer, but bob is the only user who can use the
repository.
As such, I'm not certain there is legal check we can make.
> > I don't think we need to worry about violating the abstraction. A
> > simple filesystem enumeration just means that the ambient user has
> > access to files in the repository.
>
> Well, I think it's possible to shunt the logfiles off to a different
> directory, and that would prevent a simple directory enumeration from
> working.
I'm convinced. I'll see what it looks like.
---------------------------------------------------------------------
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:26:18 2003