> From: Bill Tutt [mailto:billtut@microsoft.com]
>> From: Sander Striker [mailto:striker@apache.org]
>
>> To continue on the authorization front...
>
>> Personally, I think acls are the way to go. That is what I am going
>> to focus on (again) in this mail. I reread what I wrote yesterday and
>
>> it was quite chaotic. Sorry about that. I also shouldn't have
>> introduced possible implementation details in the form of svn_acl_t.
>> So, here, a retry at a starting point for a discussion on
>> authorization.
>>
>
> I'm going to slightly reorder these points to help discussion.
You forgot to put '3. Ordering' in. [sidenote: if you are going
to respond to the concept, please reply to the original mail
with all the points in it]
>> 2. Types (ACLs and DACLs)
>>
>> Apart from having ACLs (that grant certain priviliges) there
>> should also be DACLs (that deny certain priviliges).
>>
>
> I totally agree here. DACLs should definitely be supported. Depending on
> where the source of your group definitions come from, it might be easier
> to insert a DACL, than to alter group memberships.
Yes, that was the point.
>> 4. Inheritence
>>
>> If there is no ACL or DACL set, the (D)ACL of the parent is
>> used. The parent is the parent directory of the item, not
>> the previous version. Typically newly created items have
>> no ACLs set and thus inherit from their parent.
>>
>
> This makes sense, and keeps things simple.
>
>> The second form of inheritance pops up its head when a commit
>> is done and a new revision of an item gets created. When this
>> happens, the ACL and DACL references are copied into the new
>> revision. This effectively makes sure that the new revision of
>> the tree has the same priviliges assigned to the users as in
>> the previous one.
>>
>
>> 1. Applicability
>>
>> ACLs should apply to items and properties, of a certain revision.
>> It is no use implementing ACLs if there are areas in the repository
>> with no access control.
>>
>> 5. Versioning
>>
>> I think we can all agree that the ACLs shouldn't be versioned
>> (ie. you can't check out a copy of some previous revision
>> because you had the rights back then).
>>
>
> IMHO, life is simpler if (D)ACL's are just based on the path to the
> resource regardless of its revision. This should get what you were after
> in #5.
No, that would fail directly in the following situation:
/foo/bar (this path has a DACL for certain users)
Now a developer decides to rename or move bar and you get:
/foo/baz
This path doesn't have the DACL. So in the new revision the denied
users can get in. Consider replacing the DACL to affect /foo/baz.
Now /foo/bar in the old revisions are opened up. Sure, duplicating
the DACL to affect both /foo/bar and /foo/baz would be a solution,
but what if in the new revision the /foo/bar name is reused for
something else? Then the denied users of the old /foo/bar are
denied access.
So, I really suggest making the ACL apply to both an item and its
revision. Maybe this goes against #5 in wording. What I meant
with #5 is that if you deny access to an item for a user now, he
should be denied access to that item in earlier revisions aswell
[it is not as simple as that, look at #7]. Maybe I should have
said that ACLs should be versioned and that special care is taken
at setting them.
>> 6. Priviliges
>>
>> There are subversion specific priviliges to grant/deny:
>> checkout, update, commit, rm, add, mv, import, annotate.
>> One for each action. And an extra action: the setting
>> of acls.
>>
>
> Why do there need to be so many privileges? Can't we simplify this to
> read/write/admin?
>
> e.g.:
> Checkout == Read Access
> Update == Read Access
> Rm == Write Access
> Add == Write Access
> Mkdir == Write Access
> Copy(src, target) == Read Access(src), Write Access(target)
> Move(src, target) == Write Access(src), Write Access(target)
> Import == Write Access
> Annotate == Read Access
> (D)ACL setting == Admin Access
Annotate is not a read access operation is it?
I think splitting out the priviliges in svn terms might be a
good thing. The [outdated] section in the design doc speaks
of defining roles which is exactly what good be achieved by
having more that just read/write/admin. For completeness
I'll paste some roles here:
visitor : checkout update
hacker : checkout update commit
core-programmer : checkout update commit add rm mv
nitpicker : checkout update annotate
admin : checkout update commit add rm mv import
god : all
offlimits: none
The 'god' and 'offlimits' ones are simple IMO. It is the
rest that can't be easily expressed in r/w/a.
>> 7. Setting
>>
>> Setting (D)ACLs is somewhat of a special action since the
>> file system is versioned. There should be special
>> consideration for branches in the code. I'll try to
>> illustrate this with an example:
>>
>> Consider directory foo and file bar(1.1). Now consider the
>> file bar to be branched (2.1 and 2.2). Imagine bar is
>> now some revisions further in the 2.1 branch. We want to
>> revoke someones access rights to our branch so we try to
>> set a DACL on 'bar'. This brings us to the interesting
>> problem of the point where bar was branched. What do we
>> do with the revisions before the branch; do we add the
>> DACL to those aswell? What do we do with the other branch?
>> Ofcourse, these choices could be presented to the person
>> adding the DACL at runtime.
>>
>> This really needs some thought.
>
> If (D)ACL's are attached to the path of the resource in the repository,
> there isn't an issue at all.
See #1 and #5 above.
> The real question is how to manage this
> strange behavior. A (D)ACL could be the perfect example of a
> non-versioned property. One way of doing that would be to have "node.0"
> (of directories) be the location for non-versioned properties. Checking
> the permission than becomes a very straightforward process:
>
> * A temporary stack of (D)ACLs to construct on our way back up the tree
>
> While we haven't reached the root of our repository:
> If current directory doesn't have any (D)ACLs:
> Set the current directory to our parent directory
> continue
> else:
> Push (D)ACLs onto the stack
>
> While the stack is non-empty:
> Pop (D)ACLs from the stack
> For each ACL:
> If the operation is disallowed:
> FAIL access check
> For each DACL:
> If the operation is disallowed:
> FAIL access check
>
> If we haven't FAILed yet, then we've succeeded.
I don't think it is that simple. Or I must be misreading it.
However, this already takes us into the details I tried to avoid in
the beginning of the discussion. Lets move this to somewhat further
in the thread when more people have had their say.
> If there was a quick way of determining the complete recursive set of
> nodes there might be faster ways to do permissions checks.
>
> Bill
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006