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.)
> 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 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 5 20:44:33 2003