On 16 apr 2012, at 15:12, C. Michael Pilato wrote:

> On 04/14/2012 11:00 AM, Hyrum K Wright wrote:
>> Good morning (in some parts of the world)!
>> 
>> I've been doing some poking around with Ev2 and copy operations on the
>> ev2-export branch, and have some observations which merit discussion.
>> 
>> In the working copy and elsewhere, all versioned nodes map to a
>> repos_relpath, and I've found it greatly simplifies things if we use
>> that repos relpath in Ev2 operations.  Since an Ev2 drive doesn't need
>> to be "anchored" anywhere, using the repos_relpath in this way is
>> analogous to using local_abspaths throughout the working copy, giving
>> every node a single canonical name.
>> 
>> However, this has implications in the world of the dreaded issue 3242.
>> For instance, if a session is parented at the root, where the user
>> cannot write, then executes write operations somewhere deep in the
>> tree, where the user does have write privileges, we will produce
>> errors.  This is obviously non-sensical and undesirable.
>> 
>> If somebody can write to /A/B/C/D, they should be able to open an
>> ra_session to any of the parents and write to their allowable paths
>> without consequence.  I know this problem has been known for some
>> time; has anybody looked at what it would take to solve it?
> 
> Hyrum, I begun some work on the authz-overhaul branch aimed at fixing this,
> but never made much progress there.  My approach was simple:  bifurcate the
> "read" permission into "read" and "exist", where "exist" meant "You can know
> this thing exists and behave accordingly, but you still can't read its
> contents."  This would not be a user-visible permission -- just an
> implementation detail.  Both "read" and "write" permissions imply having
> "exist" permission.  And the rule is, "If you can know N exists, you can
> know that all of N's parents exist."
> 
> CollabNet's modified ViewVC in its Enterprise Edition product implemented
> this sort of functionality, and the result was that users could always see
> the root directory, and any paths inside it necessary to navigate down to a
> path to which they had explicit read permission.  Very, very handy.


Agree, very handy. We produce a CMS based on Svn and this is exactly what we 
wish for. If a user has the URL to /A/B/C/D, he basically already knows about 
the parents.

I have not had time to follow the Inherited Properties thread completely, but 
this is kind of related. One could argue that if a user knows about the URL to 
/A/B/C/D, then what is the harm in letting him read the properties of the 
parent directories? A significant simplification at the cost of not being able 
to store secret stuff in directory properties (file properties would still be 
safe).

 



Reply via email to