On Fri, Sep 05, 2003 at 12:19:37PM -0400, Greg Hudson wrote:
> On Fri, 2003-09-05 at 11:19, Marc Singer wrote:
> > The BDB backend is a process running within the context of a user, no
> > what operating system this happens to execute on. If the privilege of
> > that user is insufficient to write to the database, any operations on
> > the repository will fail. We can check for this kind of failure.
>
> Aha, now I get it. I can further break this down into two kinds of
> failure tests:
>
> (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. This is a bonafide FU in
the systems configuration. 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.
> (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.
> In addition to portability concerns (which are probably manageable), the
> difficult part about writing tests for these failures is that we don't
> want to violate the Berkeley DB abstraction. But BDB does have a
> function to list all logfiles, so I think both tests are probably still
> doable. So, +1. Someone should submit a patch or, failing that, file
> an issue. Even if (2) turns out to be difficult, (1) shouldn't be very
> hard, and that would solve 90% of the problem.
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. Whether those files are BDB or
some other applications isn't really interesting. AFAICT, there is no
currently valid configuration where a user can read/write to the
repository *and* should be legally prevented from writing to other
files in the repository.
In the event that we switch to another DB that uses a server process,
a backend check will be written for it.
I'll submit a patch for review.
Cheers.
---------------------------------------------------------------------
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:39:19 2003