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

http MERGE authorization problem

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-07 17:31:46 CEST

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


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

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.


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

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.