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

Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 14 Apr 2011 13:11:31 -0400

On 04/14/2011 11:47 AM, Hyrum K Wright wrote:
> On Wed, Apr 13, 2011 at 4:47 PM, <rhuijben_at_apache.org> wrote:
>> Author: rhuijben
>> Date: Wed Apr 13 21:47:24 2011
>> New Revision: 1091928
>> URL: http://svn.apache.org/viewvc?rev=1091928&view=rev
>> Log:
>> Fix issue #2381: "Cannot commit multiple WC paths which lack a common parent
>> directory" by making the commit processor determine which locks it needs in
>> which working copy.
> I've not looked at the code, but am just wondering about a theoretical
> point here. Could the approach fall victim to the same cause as issue
> #3242? Specifically, if all the commits are done in the same editor
> drive, and that editor drive is rooted somewhere outside of the
> readable or writable location for the user doing the commit, would we
> get authz denials?

I would expect that this could happen, yes. But the same could happen in a
single working copy, too, couldn't it? I'm thinking of a sparse checkout at
the root with authz like this:

   username = r

   username = rw

   username = rw

And then 'username' tries to commit to both the trunk and a branch at the
same time.

> (Just another reason to introduce the eXecute bit in our authz paradigm...)


C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-04-14 19:12:06 CEST

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.