You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@wandisco.com> on 2012/04/14 17:00:08 UTC
Ev2 and Authz
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
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Ev2 and Authz
Posted by Branko Čibej <br...@apache.org>.
On 17.04.2012 19:48, Branko Čibej wrote:
> The related right is called "directory traversal" and is, indeed,
> orthogonal to read and write permissions on directories (which are
> usually further split into read/write contents and read/write
> attributes). It is a property of directories, not leaf objects.
>
To clarify: the difference between "traverse" and "read (contents)"
permisions for directories is quite important. If you're allowed to
traverse, but not read, you have to know the path of a subordinate
object in order to be able to access it, modulo the object's own
permissions. In other words, you cannot discover the names of
subordinate objects by reading the directory contents.
-- Brane
Re: Ev2 and Authz
Posted by Branko Čibej <br...@apache.org>.
On 16.04.2012 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."
Can we please not reinvent the wheel re: ACL terminology and semantics?
The related right is called "directory traversal" and is, indeed,
orthogonal to read and write permissions on directories (which are
usually further split into read/write contents and read/write
attributes). It is a property of directories, not leaf objects.
Granted that you may be able to simplify to what you propose, I've
always found it to be a bad idea to /start off/ with a simplified model.
-- Brane
Re: Ev2 and Authz
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 17, 2012 at 5:47 AM, Julian Foad <ju...@btopenworld.com> wrote:
> We should be very cautious about proposing an apparently "simple" special case like that. A file has properties and
> text content; a directory has properties and children; that's how it is in Subversion. Saying that a user should be able
> to read part of a directory (its properties) and not the other part (its children) is breaking that relatively simple abstraction,
> and breaking abstractions in that way makes complications for all other software layers that try to build on top of the
> foundation, not to mention for the users' mental models. At first hearing, it doesn't sound like there could be any major
> repercussions, but after a while I suspect we might regret it.
I do not think the area here is as gray as you might. After all,
today we basically force people to essentially do the same thing by
adding a lot of rules to mimic it.
[repos:/]
* = r
[repos:/project1]
* =
[repos:/project1/someFolder]
* = rw
[repos:/project2]
* =
[repos:/project3]
* =
The proposal would be to save the user from not needing to add these
rules to get the same behavior.
There is of course still some gray area in that today the user has to
go out of the way to write these rules, so they are in control. But
if they create the rules, it seems like our code already know how to
handle them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Ev2 and Authz
Posted by Thomas Åkesson <th...@akesson.cc>.
On 17 apr 2012, at 11:47, Julian Foad <ju...@btopenworld.com> wrote:
> Thomas Åkesson wrote:
>
>> 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).
>
> We should be very cautious about proposing an apparently "simple" special case like that. A file has properties and text content; a directory has properties and children; that's how it is in Subversion. Saying that a user should be able to read part of a directory (its properties) and not the other part (its children) is breaking that relatively simple abstraction, and breaking abstractions in that way makes complications for all other software layers that try to build on top of the foundation, not to mention for the users' mental models. At first hearing, it doesn't sound like there could be any major repercussions, but after a while I suspect we might regret it.
Julian, I tend to agree with your objections, as indicated by my cautious wording. I was pushing the envelope a bit since access control might be a significant hurdle for inherited properties.
/Thomas Å.
Re: Ev2 and Authz
Posted by Julian Foad <ju...@btopenworld.com>.
Thomas Åkesson wrote:
> C. Michael Pilato wrote:
>> 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.
Yes, that behaviour sounds sensible to me (just from the peanut gallery), whereas ...
> 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).
We should be very cautious about proposing an apparently "simple" special case like that. A file has properties and text content; a directory has properties and children; that's how it is in Subversion. Saying that a user should be able to read part of a directory (its properties) and not the other part (its children) is breaking that relatively simple abstraction, and breaking abstractions in that way makes complications for all other software layers that try to build on top of the foundation, not to mention for the users' mental models. At first hearing, it doesn't sound like there could be any major repercussions, but after a while I suspect we might regret it.
- Julian
Re: Ev2 and Authz
Posted by Thomas Åkesson <th...@akesson.cc>.
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).
Re: Ev2 and Authz
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand