You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sander Striker <st...@apache.org> on 2001/09/04 00:12:16 UTC
Authorization
Hi,
This is the second part of authentication and authorization.
[the exact same thing regarding authentication was discussed
by the svn team earler and is in 'notes/auth_proposal.txt']
Authorization is quite an issue. Most cvs repost admins will
know about the cvs_acls.pl script that is hooked to commitinfo.
This allows you to restrict commit access on paths in the repos.
Ofcourse this system is limited. [sidenote: Greg pointed out
that cvs_acls.pl can easily be relaced with apache authorization]
Other access restrictions are enforced by filesystem permissions.
With subversion we have a chance to get this stuff 'right'. But
that isn't easy.
The first thought that came up was to add the authorization to the
network layer, like the authentication. This is limited though
and puts you in a corner when it comes to implementing. Also,
there would be much duplication, since each ra layer has to
implement it, to be effective. If multiple systems would use
different config layouts, there would be administrative duplication
aswell. This is ofcourse something we don't want, so lets throw
this idea out.
On to the next idea. ACLs in the repository. This seems like
a good idea. It has some issues, but these should be solvable
(be it through documentation or code). To implement acls in
the repos, we could use the auth_hook idea in
notes/auth_proposals.txt. We can feed it the acl checking hook
once that is implemented.
How would the acls look like?
typedef struct svn_acl_t svn_acl_t;
struct svn_acl_t
{
svn_acl_t *next;
const char *user; /* Or maybe a user id? */
const char *group; /* Or maybe a group id? */
apr_uint32_t access_flags;
};
If both user and group are NULL, the acl is the ALL
acl. The user and group field can't both be valid.
Therefore, one should always be NULL if the other is
set.
access_flags is a bitfield:
#define ACL_Fxxxx (1 << 0)
#define ACL_Fxxxx (1 << 1)
etc.
#define ACL_FALL (all of the above added up)
These have to match the actions a user can perform.
I would like these to match the command line more than
the internals, so it is clearer to an admin (and to
people not as familiar with the svn internals. Also,
we don't know what will change in the fs layer when
we present a database backed fs. So, having flags for
'checkout, update, commit, rm, add, mv, import, annotate'
seems like a good idea. I don't know if this can be
implemented, but that is for another day :)
Obviously we also need a flag for acl setting.
ACLs are inherited. If the parent has an acl and a child
has not, or when the check fails to match all acls in the
child, the check is performed on the parent instead.
Order of acls should not matter. If an item has an acl
chain like this:
next -> next -> NULL
striker commiters
ACL_FCHECKOUT| ACL_FALL
ACL_FUPDATE
And striker would be in the group commiters, then he should
only have checkout and update privilidges on this item.
If the first acl and the second were reversed the result
should be the same.
If a user 'gwappo' would have been checked against the above
chain (he isn't in commiters) the check would have to fall
back to the parent acl chain, because there is no match in this
one.
ACLs should not be versioned (ie acl changes do not have to
be tracked), they do apply to a single version of an item and
all next versions.
When an acl is set/changed on an item later on, this should
optionally propagate back to earlier revisions. Therefore, it
seems logical to put acl chains in by reference, so only one
actual acl chain needs updating. Ofcourse this brings up a
problem. If in the history of the item the item was branched,
the acl applying should stop and ask the admin what to do:
1 - continue to apply the new acl onto earlier revisions
thereby influencing privilidges in the other branch aswell;
2 - stop applying the new acl at this branch, only the current
branch gets the new acl. In the implementation this would
mean copying the new acl and putting that on the first
revision of the item in the current branch.
Ok, 2AM here, calling it a nightzzzz...
Questions/remarks in my head:
- Where should ACLs be stored?
- We should have a svn acl command.
- How do we do the user -> group mapping?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authorization [2]
Posted by Olof Oberg <mi...@pedgr571.sn.umu.se>.
Greg Stein wrote:
> There are two items going on here:
>
> 1) the ACL model (or capabilities or whatever) *model* used by the server
> 2) how to marshal changes to the ACL data over the wire
>
> We use WebDAV for marshalling over the wire. When we support ACLs in SVN,
> then we'll use the WebDAV ACL mechanisms.
>
> Note that the ACL extensions have gone through IETF Last Call. There ought
> to be an RFC by the end of the year.
I guess I was a little ambiguous.
The requirements/goals for WebDAV-ACL should give an idea about
what Subversion needs (I got the feeling that a part of the
discussion was to determine that) and even more insight can be
found in the RFC.
Disclaimer: it is a long time since I read the cited documents,
but I thought I would mention them so that not the proverbial
wheel is reinvented.
/mill
--
#############################################################
# S-mail: Olof Oberg # mill@pedgr571.sn.umu.se #
# Pedagoggr. 7A # mill@ludd.luth.se #
# S-907 30 Umea # tdv94oog@cs.umu.se #
# Phone: 090-197395 # http://pedgr571.sn.umu.se/~mill #
#############################################################
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authorization [2]
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 05, 2001 at 09:23:18PM +0200, Olof Oberg wrote:
> Hi,
>
> has anyone taken a look at the ACL extensions to WebDAV
> ( http://www.webdav.org/acl/ )?
>
> Those requirements should be enough for Subversion.
>
> Compatibility with other WebDAV compliant tools is also
> a Good Thing(tm).
There are two items going on here:
1) the ACL model (or capabilities or whatever) *model* used by the server
2) how to marshal changes to the ACL data over the wire
We use WebDAV for marshalling over the wire. When we support ACLs in SVN,
then we'll use the WebDAV ACL mechanisms.
Note that the ACL extensions have gone through IETF Last Call. There ought
to be an RFC by the end of the year.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authorization [2]
Posted by Olof Oberg <mi...@pedgr571.sn.umu.se>.
Hi,
has anyone taken a look at the ACL extensions to WebDAV
( http://www.webdav.org/acl/ )?
Those requirements should be enough for Subversion.
Compatibility with other WebDAV compliant tools is also
a Good Thing(tm).
/mill
--
#############################################################
# S-mail: Olof Oberg # mill@pedgr571.sn.umu.se #
# Pedagoggr. 7A # mill@ludd.luth.se #
# S-907 30 Umea # tdv94oog@cs.umu.se #
# Phone: 090-197395 # http://pedgr571.sn.umu.se/~mill #
#############################################################
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Authorization [2]
Posted by "Douglas S. Keester" <dk...@earthlink.net>.
On Wednesday 05 September 2001 12:32, Sander Striker wrote:
> > 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? ;)
>
Vote early and vote often, I guess. ;-)
> > 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?
>
If we use the assumption of "that which is not specifically granted is
denied," then simply removing the user from the group, or putting the user in
a different group with different privs will achieve the same goal. We should
only have to specify in one place what the access controls are.
I understand more what you are saying now, but I still think that having both
will be a little redundant.
> > 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.
>
Let me see if I am complerely understanding what you are saying.
User Doug wants to commit file trunk/my_proj/foo/bar/baz.c. The system now
has to determine the order of ACL importance (allow, deny or deny, allow).
Next it must check the ACL and DACL on each directory in the path. Then it
must check the ACL and DACL on the file itself. If those cheacks all fail we
fall back to the top level ACL and DACL. If that fails we deny access. This
is a total of 13 operations. There is one to determine ordering, two for the
ACLs and DACLs on each part of the file path, and two for the top level ACL
and DACL. This seems like a lot of work.
> > 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.
>
"Ah, I see," said the blind man to his deaf wife. :-)
> >> 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.
>
I realize that is not the ordering which you were speaking about.
My thinking here is that if there is only one ACL or DACL then the only
ordering we have to worry about is checking a directory before checking its
subdirectory.
> >> 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 :)
>
Well, I had to get at least one plug in. ;-)
> > > 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.
>
Naturally any solution needs much TLC in the implementation.
I am still of the opinion, however, that if we use less rope, we will be less
likely to hang ourselves.
> 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.
>
This issue does warrant more discussion, but I agree that there are probably
more important things to worry about before 1.0.
> > 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
>
You are welcome. I am glad to be able to help in some way.
-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
RE: Authorization [2]
Posted by Sander Striker <st...@apache.org>.
> 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
Re: Authorization [2]
Posted by "Douglas S. Keester" <dk...@earthlink.net>.
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.
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
> ---
> 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.
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? Or
when a user is defined in both such that the ACL and the DACL conflict?
> 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.
> 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.
> 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.
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.
-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
Authorization [2]
Posted by Sander Striker <st...@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.
---
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.
2. Types (ACLs and DACLs)
Apart from having ACLs (that grant certain priviliges) there
should also be DACLs (that deny certain priviliges).
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.
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.
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).
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.
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.
6. Storage
ACLs could be stored seperately, with a references to them
stored as properties (I think). This is more an implementation
detail.
So far my thoughts (for now).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org