Subject: RE: CAP Issue: Decreed VCARs

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 7 Aug 2001 06:08:38 -0400

Hi,

There is open discussion about decreed VCARs and in the past there has been
discussion about inhereitence rules.

E.g. ...How do you know, given a particular VCAR, whether or not it is
decreed? Since
decreed vcars cannot be overridden, we have to know.  For example

Today we have VCARs that look something like:

		 BEGIN:VCAR
                CARID:Users Default Access
                GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
                DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
                 VALUE="Users Default Access"
                 ;OBJECT=METHOD,VALUE=DELETE,MODIFY
             END:VCAR

Suppose that we add some semantics to a VCAR that specifically address some
of the inheritence rules.

1) Allow / Prohibit inheritable permissions to be modified at a lower level.

	Allow-Override | No-Override

2) Allow / Prohibit inheritable permissions from parent to propagate to this
object.

	Inheritance-On | Inheritance-Off

3) Reset permissions on all child objects and enable propagation of
inheritable permissions.

	Reset-On | Reset-Off

So a VCAR that an administrator wants to set on all child objects could be
defined as:

		 BEGIN:VCAR
                CARID:Users Default Access
		    CAR-INHERIT: No-Override
                GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
                DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
                 VALUE="Users Default Access"
                 ;OBJECT=METHOD,VALUE=DELETE,MODIFY
             END:VCAR

If a user / admin needs to apply a change to all of the child objects then
the example would become:

		 BEGIN:VCAR
                CARID:Users Default Access
		    CAR-INHERIT: No-Override; Reset
                GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
                DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
                 VALUE="Users Default Access"
                 ;OBJECT=METHOD,VALUE=DELETE,MODIFY
             END:VCAR

If an admin or user wants to set a default but wants to enable others with
sufficient rights to modify child objects then a VACR could be defined as:

		 BEGIN:VCAR
                CARID:Users Default Access
		    CAR-INHERIT: Allow-Override
                GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
                DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
                 VALUE="Users Default Access"
                 ;OBJECT=METHOD,VALUE=DELETE,MODIFY
             END:VCAR

If the CAR-INHERIT property is not specified the default behavior would be
Allow-Override and Inheritance-On.

---

From: [email-masked] (Steve Mansour)
Date: Tue, 07 Aug 2001 09:13:49 -0700

Paul,

This looks much more palatable.  Can you explain Reset on/off a little more.  I
don't quite follow it.

-Steve

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 07 Aug 2001 16:22:37 -0500

"Paul B. Hill" wrote:
> decreed vcars cannot be overridden, we have to know.  

Isn't it an implementation detail?  If it can't be overridden,
that could be reflected in the error message you get when you try to
override one?

But CAP doesn't have a good way to request additional VCARs anyway.

-- 
                                           David Nicol 816.235.1187
free Dmitry Skylarov

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 8 Aug 2001 03:48:17 -0400

This looks much more palatable.  Can you explain Reset on/off a little more.
I
don't quite follow it.

OK, "reset" might not be the best term, but the intent is that if the
inherited VCAR allows it, reset indicates that inheritence from above should
be blocked, and the new permissions are then inherited by subsequent child
objects. If the object and child objects already exists and the "reset" is
part of a change, then the new permissions will be explicitly applied to the
already existing child objects, possibly changing their previously inherited
VCARs.

Paul

---

From: [email-masked] (Steve Mansour)
Date: Wed, 08 Aug 2001 08:21:57 -0700

sman wrote:

> I don't quite follow it.

"Paul B. Hill" wrote:

> be blocked,

OK, that makes sense in terms of the functionality you're trying to achieve. It
provides a mechanism to keep you from being "surprised" when you move an object
from one area of the hierarchy to another.

> and the new permissions are then inherited by subsequent child
> objects.

Do you mean that subsequent child objects have all permissions denied except
those granted by the current vcar?  What happens if we encounter multiple vcars,
all of which have the same OBJECT in their GRANT property and all of which
indicate "reset" ?

> If the object and child objects already exists and the "reset" is

So, it would be a process of recursing downward and resetting all vcars for
objects "beneath" the OBJECT targeted ?

-Steve

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 8 Aug 2001 11:29:24 -0400

>...Do you mean that subsequent child objects have all permissions denied
except
those granted by the current vcar?  What happens if we encounter multiple
vcars,
all of which have the same OBJECT in their GRANT property and all of which
indicate "reset" ?

Good catch. I was modeling this after a system that assumes everything is
granted unless specifically denied. The opposite of the current CAP model.
Needs some further thought.

Yes.