Subject: Re: VCAR question

From: "John Stracke" <[email-masked]>
Date: Tue, 11 Dec 2001 17:44:10 -0500

>Does "write" permission to a VAGENDA give you the right to move another
>VAGENDA into it?

It does seem like it should.

Er...does it give you the right to create subagendas, and create 
components within them? If so, then I'd say yes, since there's no way to 
distinguish (after the fact) between:

(a) Move VAGENDA X into VAGENDA Y.
(b) Create VAGENDA Y2 inside VAGENDA X; for each component C in Y, create 
a copy C2 in Y2; delete Y.

Obviously, (b) is less efficient than (a), but has the same net effect, so 
we shouldn't set any rules that cause people to do (b) when they mean (a).

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|I'm not a bibliophile, I'm a bibliophiliac. Put me in a|
|bookstore, & my wallet bleeds.                         |
\=======================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 11 Dec 2001 17:04:19 -0600

Just a question - and prefaced by the note that I have not fully read
through the newest draft with VAGENDA so this may be answered elsewhere.

Can a VAGENDA contain a VCAR? If so then isn't having "write" permission to
a VAGENDA with the ability to move another VAGENDA into it the same has
having full rights since you could create VCARS?  Or am I missing something?

Just a thought,

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Tuesday, December 11, 2001 4:44 PM
To: CalSched IETF
Subject: Re: VCAR question

---

From: [email-masked] (Steve Mansour)
Date: Tue, 11 Dec 2001 15:23:57 -0800

> through the newest draft with VAGENDA so this may be answered elsewhere.

it's in CAP

> Can a VAGENDA contain a VCAR?

yes

> If so then isn't having "write" permission to

we were just wondering if this is enough of a special case.  It seems like it
could be a special case.  Just interested in people's thoughts.

-Steve

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 11 Dec 2001 19:30:25 -0500

>...Can a VAGENDA contain a VCAR? If so then isn't having "write" permission
to
>having full rights since you could create VCARS?  Or am I missing
something?

A VAGENDA can contain most things, so at first glance, having the ability to
move another VAGENDA into an existing one, or create a new sub-VAGENDA,
feels like having full rights, it might not be.

If our access control model is changed to:
1) default access is grant
2) inheritence evaluation starts at the root and you work your way down
3) evaluation stops when an explicit DENY is reached

Then you could give someone CREATE or MODIFY access on a VAGENDA to someone
and use other VCARS to still limit what could be done in the "sub" VAGENDAs
introduced by the user.

Paul

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 11 Dec 2001 19:03:34 -0600

Paul,

Hmmm this raises another question - what does a "VCAR" apply to?

i.e. does it apply to a PARTICULAR object - i.e. specified by a UID?

	- to a particular type of object? (all VEVENTS?)
	- to a particular "user" for all objects? (this raises the serious question
of "what is a user?"
	- to some other means of specifying objects?

I guess what I am asking is how in a multi-level VAGENDA environment, where
each VAGENDA can contain VCALENDARS with other objects - do these VCARs in
practice work?

Shannon
(note - CAP is not my area of greatest expertise - so apologies in advance
if this is dealt with in draft 6 of CAP)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul B. Hill
Sent: Tuesday, December 11, 2001 6:30 PM
To: Shannon J. Clark; John Stracke; CalSched IETF
Subject: RE: VCAR question

to

Paul

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Dec 2001 23:19:06 -0700

> 1) default access is grant

I thought the security guru's did not like (1).

> 2) inheritence evaluation starts at the root and you work your way down

That is the way it is now.

> and use other VCARS to still limit what could be done in the "sub" VAGENDAs

With a VCAR (as it is now - default is DENY), you can not create without
permission. So if you don't want to give permission to create new
objects, then don't give permission to create those objects.
I can't see the difference. If you do not have a:

	GRANT ... OBJECT=VAGENDA ...

then, you can;t do it now.

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Dec 2001 23:36:35 -0700

> Hmmm this raises another question - what does a "VCAR" apply to?

To the constrains in the VCAR, by METHOD, component, property,
parameters, and property values, as applies to the named UPN's
in the VCAR and constrained to the scope and below by inheritance
and where it is placed in the CS (CS, VAGENDA, Calendar, ...).

> i.e. does it apply to a PARTICULAR object - i.e. specified by a UID?

It can.

>         - to a particular type of object? (all VEVENTS?)

It can.

>         - to a particular "user" for all objects? (this raises the
	    serious question of "what is a user?"

It can apply to UPN's.

>         - to some other means of specifying objects?

I don't understand that question.

> I guess what I am asking is how in a multi-level VAGENDA environment,
> where each VAGENDA can contain VCALENDARS with other objects - do
> these VCARs in  practice work?

Big question. ACL's of any kind are a pain. In calendaring
with the ability to not only share objects, but to share specific
parts of objects, any ACL is going to be complex.