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

RE: Authorization [2]

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2001-09-05 05:34:42 CEST

> 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.

> 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.

> 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.

> 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

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

> 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. 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
     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.

If there was a quick way of determining the complete recursive set of
nodes there might be faster ways to do permissions checks.


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

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.