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

Re: mod_authz_svn bug with multiple directories

From: Robert Spier <rspier_at_pobox.com>
Date: 2004-03-03 19:18:25 CET

> > I think I may have found a bug (or at least "user assumption failure")
> > in mod_authz_svn.
>
> I'd classify it as a mix between 'pilot error' and bug. ;-)

60/40? 50/50? ;)

> > a commit to both of those two directories will result in a MERGE
> > request to the directory above. (/test/level1)
> > BUT - since the user can't write there, the MERGE result fails.
> >
> > *kaboom*
>
> Correct. To fix, guest would need rw on the parent directory as well.
> However, committing independently should resolve the problem. Does
> it?

Yes.

> I'm not sure what else we can do here. Perhaps we could build in some logic
> that if someone can write to a child directory, MERGE should then succeed?
> (i.e. an implicit w permission to call MERGE.) Although I think that might
> open us up a bit too much. -- justin

Right. But it might be interesting to do anyway... do we have any way
of knowing that the MERGE was part of the same "session" as the PUT's?
They're individual HTTP actions, so the answer may be "no" -- although
even though the PUTs succeed, the MERGE fails, so the whole
transaction is never recorded.. so the answer is probably yes. In
that case, we can open it up only for the scope of the transaction,
which probably is ok.

One "real world" example of where this is going to bite us is when
we've given someone access to lib/Foo and tests/ - when they make a
change to lib/Foo, we also want them to make changes to tests/ and it
would be grrrrrrrrrreat if that could be one change.

-R

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 3 19:17:23 2004

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.