> Hello, everyone.
>
> On Tuesday 04 September 2001 08:52, Sander Striker wrote:
> > 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 think that we really need to explore other options. ACLs will
> work, but are perhaps not the best solution.
>
> My vote is for a capabilities based system.
Voting already? ;)
> The basic idea of a capabilities based system is that each object in the
> system has to ask if it has permission to perform an action
> before it can do it.
>
> To adequately explain capabilities based computing would take too
> long, so I
> will just point you all to a web page with some good overview material.
>
> http://www.erights.org/elib/capability/overview.html
Ok, will take a look at that.
>> ---
>> 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.
>>
>
> Granted. Every object in the subversion system needs to have
> access controls associated with it. This includes users as well as data
> and metadata.
>
>> 2. Types (ACLs and DACLs)
>>
>> Apart from having ACLs (that grant certain priviliges) there
>> should also be DACLs (that deny certain priviliges).
>>
>
> Redundant, redundant. Having both is unnecessary since ACLs and DACLs are,
> as you define them, simply the logical inverse of each other.
No, this is not redundant. Consider having a group and you wish
to grant this entire group a certain privilige. Now, there is one
user (in that group) you wish to deny that privilige. Does this mean
I need to create a new group without that user?
> Having to specify both will also lead to inconsistencies within
> the access
> control system and thereby lead to security holes. There needs to be one
> authoritative source for access control information. For example
> what happens
> when a user is not defined in either the ACL or the DACL for an object?
There is always a top level acl. It should get set when the repos is
first created.
> Or when a user is defined in both such that the ACL and the DACL conflict?
That is where the ordering comes in. If the ordering is allow,deny then
the user is denied access. If the ordering is deny,allow the user is
granted access.
>> 3. Ordering
>>
>> ACLs and DACLs are ordered. The first matching ACL and DACL
>> are looked up. I think that allowing the configuration of
>> allow,deny ordering would be a plus. This would be analogue
>> to the 'Order' directive in apache.
>>
>
> Now we have access controls for our ACLs. We also have to worry now about
> which ACLs supercede other ACLs. IMHO, we should only have to do one
> query per object of the access control system to determine what
> is allowed.
> In the presented system we would have to do several lookups per
> object We are
> building a house of cards by requiring a set processing order for
> the access
> controls.
>
> The only ordering that should be necessary is when an object in the system
> tries to access another nested object. For example user Doug
> tries to access
> the file trunk/my_proj/foor/bar/baz.c. Here the system does at most one
> access control lookup for each of the directory object and one
> for the file
> object. If any of those lookups return a "permission denied" then
> the entire
> operation fails.
This was not the ordering I was talking about. It is the ordering of
the ACLs for one single item.
>> 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.
>>
>> 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.
>>
>
> You are correct that this is a fairly hairy issue. I personally
> would rather
> see us side-step this issue by making access controls discrete
> and by having
> a default set of controls with which each file begins. (Similiar
> to a umask.)
> This could be different in the case of a "branch" where at the time of the
> branch both sets of files are identical. At this point their
> access controls
> should probably be identical as well.
>
> > 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).
> >
>
> I can not help but agree with you on this one. Versioning the
> access controls
> would probably be a nightmare.
:)
> > 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.
> >
>
> I agree that we will probably need such fine grained controls with in
> subversion. The problem here is that at this level of complexity ACLs can
> become rather cumbersome.
>
> This, by the way, is where a capabilities based system would really shine.
*grin* shameless plug :)
> > 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.
> >
>
> I am going to assume here that the access control mechanism will
> be some sort
> of non-versioned property of each object within the system. It should be
> gettable and settable just as all other properties are, except that this
> ability is restricted to the administrator, or perhaps the object
> owner, only.
>
>> 6. Storage
>>
>> ACLs could be stored seperately, with a references to them
>> stored as properties (I think). This is more an implementation
>> detail.
>>
>
> I agree that we should do our best to avoid implementation details at this
> point.
>
>> So far my thoughts (for now).
>>
>> Sander
>>
>
> Your system is not a bad first attempt. It is overly complex,
> however. Again
> here is a place where we need to apply the K.I.S.S. principal.
> Security needs
> to be simple and effective. Security will decrease as complexity
> increases.
I'm not in full agreement on the latter two statements. If
it is specified correctly and implemented as such there will
be no problem.
But, I'm beginning to think that shoving the entire discussion to
post 1.0 per Gregs suggestion a while back wouldn't be a bad idea,
given the complexity of authorization in a system like subversion.
> A few arguments in favor of capabilities:
>
> 1) It is conceptually simple. Every object has things that it has
> permision
> to do and things that it has no permission to do. A more simple
> concept will
> very likely lead to more simple code.
>
> 2) Capabilities are more universal. A file object has
> capabilities as well as
> a user object.
>
> 3) A system of ACLs or DACLs could be implemented on top of the
> capabilities
> model.
>
> 4) The Capability model always requires objects to ask for
> permission to do
> an action.
>
> 5) Capabilities are just properties of objects. This should fit in better
> with the overall system design.
Thanks for the feedback, will surely check it out to get up to speed again.
Sander
> -Doug
> --
> Douglas S. Keester
> dkeester@earthlink.net
> UNIX guy
> --
> "If I survive this experience, thought Georges
> furiously, I am going to kill that cricket."
> -Daniel Keys Moran
> "The Armageddon Blues"
>
>
>
---------------------------------------------------------------------
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