http MERGE authorization problem

On the users list, Stuart has noticed a problem with mod_authz_svn.
Here's the thread:

http://www.contactor.se/~dast/svnusers/archive-2004-04/0391.shtml
http://www.contactor.se/~dast/svnusers/archive-2004-04/0397.shtml

In summary, Sander, CMike and I have boiled the problem down to this
general scenario:

1. a user has read access everywhere, and write access only on
/foo/bar/.

2. the user tries to 'svn cp /baz /foo/bar/baz-branch'.

3. mod_authz_svn allows the MKACTIVITY unconditionally (we need to fix
this, but that's a separate bug).

4. mod_authz_svn allows the creation of /foo/bar/baz-branch, according
to the authz file's rules.

5. then a "MERGE /" request comes in, and authorization is denied, since
the user has no write access on '/'.

The problem here is step 5: libsvn_client is anchoring the commit on
the common parent of source and target. It's actually *required* to do
this for 'svn mv', but our code is currently optimized to do the same
thing for 'svn cp', since those commands often share a lot of code.

Rather than look for anchor-target workarounds, I'm wondering if we
can't solve the problem by teaching mod_authz_svn to simply ignore the
URI argument to MERGE.

In theory (according to RFC), the URI to MERGE is a parent-dir of some
kind, which identifies potential merge targets. But if you read the
very bottom section of our notes/webdav-general-summary (and our
comments at the top of mod_dav_svn/merge.c), you can see that our own
implementation of MERGE is very simple. I believe that the URI passed
to MERGE is completely ignored: we only care about the activity
"source" passed in the headers and request body, and automatically merge
*all* targets in the activity.

Therefore, I wonder if we just shouldn't make mod_authz_svn ignore the
URI argument to MERGE. In my opinion, MERGE and MKACTIVITY should both
be allowed as long as the user has *some* write access somewhere in the
repository. The URI doesn't need to be checked.

Thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 17:33:22 2004