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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-04-16 15:12:57 CEST