On Wednesday 05 September 2001 13:08, Bill Tutt wrote:
> > From: Douglas S. Keester [mailto:dkeester@earthlink.net]
> >
> > On Tuesday 04 September 2001 08:52, Sander Striker wrote:
>
> [... Sander made some of my points for me already, so I'll stick to
> stuff he didn't touch on ...]
>
> > > 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.
>
> The default set of controls is not having a specified ACL, which implies
> that it inherits all of its ACLs from its parent directories. Having the
> root of the repository have no ACLs is illegal.
>
Ah, I guess I was a little confused. I was assuming that a specified ACL
would be required. :-)
> [...]
>
> > > 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.
>
> Err, can you think of a reason why you need such fine grained controls?
>
Recently I was required to clean out part of a CVS repository. The only
action that I was foing was removing files. Had I wanted to farm this off to
someone else it would have been handy to be able to restrict that person to
the ability to remove files within a certain directory.
As the admin I might want to allow my users to the ability to add to the
repository, but not to remove anything. This way none of the developers can
destroy my company's IP which is contained within subversion.
> > This, by the way, is where a capabilities based system would really
>
> shine.
>
>
> How does this help at all? You generally have lots of fine grained
> capabilities to manage in a capabilities system don't you?
>
I believe capabilities to be a good method for managing fine grained access
controls. If it is determined that subversion does not need such fine
granularity, then the capabilities model, naturally, will loose appeal.
> > > 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.
>
> Object owner doesn't make sense for Subversion. Admins "own" everything.
>
Then each admin should have this ability within his area of influence.
> > > 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 definately don't agree with these statements. The proposed model isn't
> actually that complicated. Especiallly if you compare it to real
> business application security model requirements. (Ordering, inventory,
> billing, and other associated systems) Capability systems are more
> useful in that area where there are so many things (data and actions)
> you need to secure. This still doesn't make it any simpler though.
>
The complexity comes from the fact that having both the DACL and the ACL are
unnecessary. Having only one would solve the problem just as well. We just
need to define one as the inverse of the other.
La perfection est atteinte non quand il ne reste rien � ajouter, mais quand
il ne reste rien � enlever. (You know you've achieved perfection in design,
not when you have nothing more to add, but when you have nothing more to take
away.) -Antoine-Marie-Roger de Saint-Exupery
The worst enemy of security is complexity. -Bruce Schneier
( see http://www.infosecuritymag.com/articles/1999/schneier.shtml)
Just because there are systems in existence that are more complex does not
mean that ours must be. K.I.S.S.
> > 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.
>
> Conceptually simple, yes. Pratically simple? No way, you end up with a
> capability for every single action you perform, and thus more that you
> need to manage. Managing more capabilities is always more complex than
> managing less.
>
Like I have said above, I am assuming that we need fine grained access
control. Capabilites are a better fit for fine granularity. If we don't need
such fine granularity, then a simple ACL system will fit the bill.
Volume of information is not the problem in a security system, complexity of
information is. A large number of simple things will always be easier to
manage than a smaller number of complex things.
> [...]
>
> > 3) A system of ACLs or DACLs could be implemented on top of the
> > capabilities model.
>
> Yep, sure could. Given Subversion's application domain, it might not be
> worth the effort though.
>
I was simply pointing out the flexibility that capabilities lend. :-)
> Bill
-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