Subject: Re: Typos, bugs, clarifications for ACI draft (i, iii, v, vi)

From: Ellen Stokes <[email-masked]>
Date: Tue, 18 Jul 2000 02:23:49 -0500

David,

At 10:59 PM 7/17/00 +0100, David Chadwick wrote:
>Ellen
>
>could you clarify a few points for me please
>
>i) section 2 says the draft is neutral with respect to implicit vs
>explicit denials, then says in 4.3 deny is the default when there is no
>access control information. These statements seem to be in conflict.

(EJS) The neutrality statement in section 2 refers to whether you
deny by granting no rights (implicit) or you provide a deny verb in
the ACI to explicitly deny rights.  We've chosen to allow either.
Also, if I remember from email many months ago, there was
discussion of what the ACI is when no ACI is explicitly defined
at the root of the DIT held by a server - and the rough consensus
was 'default is deny'.

>ii) 4.3 precedence of subjects has public in the bottom 2 levels and
>this in the middle two levels. Can you explain this to me please.

(EJS) will respond in separate email

>iii) delete this entry permission. What happens if the entry has
>subordinates. Are permissions needed for the subordinates or not.
>The text is mute on this point, although it does mention that no
>permissions are needed on attributes in the entry.

(EJS)  The intent here was to provide the same semantic as X.500.
However, I think we may have missed the point you mention about
subordinates.  It seems to me that if you the entry you're deleting
is a leaf entry, then no problem.  If there are subordinates, then
you can't just delete an entry in the middle of the DIT, but also
need permisison to delete each subordinate.  What does X.500 do?

>iv) add is permission for below an entry, but import appears not to
>be ("permissions at the source location", not "below the source
>location"). I dont think it is helpful to have different rules here (or
>different text). Can we be consistent please as adding or importing
>seem to be very similar in where the new entries are placed.

(EJS) will respond in separate email

>v) bottom of 4.2.2, example of subtree#grant. If the grant list is
>empty, why does this mean deny all?? See also comment i) above.

(EJS)  No rights are granted and no rights means deny (see i) response)

>vi) section 4.2.4, Can you add text after role and ipAddress to say
>what these mean (all the other subjects have some).

(EJS) Oops.  Here's the proposed text:
ipAddress - defined as IP Address in dotted decimal form or domain
                     name; wildcards allowed (see BNF)
role - <One could define using the existing group object class definitions;
                (from teminology section, draft 05) asserts a subject's 
organization
                position and entitlement to perform the operations 
appropriate to that
                organizational position; where group is just a collection>
          <Or one could define a role object that looks identical to the 
group object>
          ---I'll have to think about the text some more for this one

>vii) section 4.3, step 2. what does 'this may also be combined with
>group to use the power of "this"' mean. Sorry to be dumb.

(EJS) will respond in separate email

>David
>
>***************************************************
>
>David Chadwick
>IS Institute, University of Salford, Salford M5 4WT
>Tel +44 161 295 5351  Fax +44 161 745 8169
>Mobile +44 790 167 0359
>Email [email-masked]
>Home Page  http://www.salford.ac.uk/its024/chadwick.htm
>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string MLJ9-DU5T-HV8J
>
>***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 18 Jul 2000 18:21:07 +0100

> >subordinates. Are permissions needed for the subordinates or not. The
> >text is mute on this point, although it does mention that no
> subordinates.  It seems to me that if you the entry you're deleting is
> a leaf entry, then no problem.  If there are subordinates, then you
> can't just delete an entry in the middle of the DIT, but also need
> permisison to delete each subordinate.  What does X.500 do?

X.500 does not have this problem as only leaf entries can be 
removed. LDAPv3 basic only allows leaf entries to be deleted, but 
there was talk of having an operation to delete full subtrees. I dont 
know the status of this, do you?

David

David Chadwick

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 18 Jul 2000 14:46:19 -0700

At 06:21 PM 07/18/2000 +0100, David Chadwick wrote:
>  LDAPv3 basic only allows leaf entries to be deleted, but

My proposal that included subtree operations for delete, copy and modify as 
extended operations has expired.  Michael Armijo wrote a draft that 
included a control to add to the existing delete operation, which also 
appears to have expired.  If there is interest, I can resubmit the draft to 
reactivate it (I have a change or two that I need to make anyway).  Of the 
two approaches I liked mine better (but I'm biased).  Michael did make some 
interesting points in favor of the use of a control.

Bruce

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 18 Jul 2000 16:55:52 -0500

David / Bruce,

I think the ldap model should use delete in the X.500 sense - the object
must be a leaf entry.

However, subtree delete becomes interesting if/when we decide to
surface the scope of ACI (entry/subtree) via your entryACI / subtreeACI
proposal.  At that point in time, then the expired subtree drafts become
interesting because you have a way actually invoke the subtree operation
and apply access control to the operation.

Comments?

Ellen

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 20 Jul 2000 09:47:50 -0500

David,

Much of the power / ease of use provided in the access
control model is by granting large numbers of people a
given set of permission based on a single ACI. 'public'
is a good example of this. The second thing that is very
powerful is the ability to give someone permission to
their own entry by placing a single ldapACI value using
'this' in the tree.

So, when we look at the subject precedence order we must
include 'this' and 'public' and define where they fit.
We've stated that more specific takes precedence over less
specific, processing stops when ldapaci values for a given
specificity level. 'This' applies to a single DN at a time
( that which matches the entry DN ) and therefore, fits in
well with authzID which also applies to a single logical DN.
Different from a group which is many member DNs )

In order to take full advantage of the pseudo-DNs they need
to apply to multiple levels. An example using 'this' :
ldapACI: group RegDeptMembers has rs perms to telephone and
              rs to secureDocs.
             THIS has w perm telephone
             authzID guest has rs to telephone

Where we have an organization, and this ACI is on the dept
node, and each person in the dept is a child of the dept node.
We want all dept members to be able to read each other's
telephone numbers, but only update their own. We also have a
visiting guest for the month who is not a dept member but
should have access to telephone numbers.

If 'this' is the same precedence as authz-ID;
User guest would come in a receive permission to read
everything and have write access to his own entry.
However, the rest of the dept would be able to read
everything on each other's entries, but processing
for their own entry would not be as desired. They would
receive 'w' for telephone by virtue of 'this' but
processing would stop because 'this' is a higher precedence
then group. So, they could change their phone number,
but not read it.

If 'this' is the same precedence as group, then the
opposite happens. All dept members can read everyone's
phone number and update their own. However, the guest
can not update his phone number. Processing would stop
after finding that he matched on the authz level for
guest, and he would not receive the permission to update
his own phone number, since that is granted by 'this'
which is at the group level.

So, really, in order to really use the power that comes
with the concept of 'this' it really needs to be combined
with either groups or authZids and that by itself, it
should not stop processing due to precedence.

The same type of thing is true with the 'public' pseudoDN.

ellen

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 20 Jul 2000 22:24:12 +0100

Date sent:      	Tue, 18 Jul 2000 16:55:52 -0500
To:             	[email-masked], [email-masked],
       	[email-masked]
From:           	Ellen Stokes <[email-masked]>
Subject:        	Re: delete permission

> David / Bruce,
> 
> I think the ldap model should use delete in the X.500 sense - the
> object must be a leaf entry.

agreed

> surface the scope of ACI (entry/subtree) via your entryACI /
> subtreeACI proposal.  At that point in time, then the expired subtree
> drafts become interesting because you have a way actually invoke the
> subtree operation and apply access control to the operation.
> 

Unless I have misunderstood the current model, or you have 
misunderstood my proposal, I think the separation out of subtree 
ACI into a separate attribute type is irrelevant to the subtree delete 
operation.

David

David Chadwick

---

From: Ellen Stokes <[email-masked]>
Date: Fri, 21 Jul 2000 09:45:20 -0500

David,

On relating the subtreeACI and subtree operation...

My thinking is that if there is a subtreeACI with a delete permission,
then when the subtree delete operation is executed on the server,
the subtreeACI is checked for delete permission and since it is set
the subtree operation succeeds.

But this specific case is uninteresting until the time at which both
subtreeACI and subtree operation exist.

Until then, I see delete used only against leaf entries (as you pointed
out that's what X.500 does) and when subtreeACI exists it would have
the semantic of stating the delete operation (or any other operation)
applies to the subtree until overridden by another ACI (either entry
of subtree).

Ellen

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 23 Jul 2000 09:26:50 +0100

Date forwarded: 	Fri, 21 Jul 2000 07:46:37 -0700 (PDT)
Date sent:      	Fri, 21 Jul 2000 09:45:20 -0500
To:             	[email-masked], [email-masked]
From:           	Ellen Stokes <[email-masked]>
Subject:        	Re: delete permission
Copies to:      	[email-masked]
Forwarded by:   	[email-masked]

> then when the subtree delete operation is executed on the server, the
> subtreeACI is checked for delete permission and since it is set the
> subtree operation succeeds.

Not so. There may be an entry somewhere in the subtree that 
forbids the deletion of that single entry. Therefore the subtree 
delete should fail, as the client does not have permission to delete 
the whole tree. This is why I said that separation of the ACI into two 
attributes made no difference at all.

> Until then, I see delete used only against leaf entries (as you
> pointed out that's what X.500 does) and when subtreeACI exists it
> would have the semantic of stating the delete operation (or any other
> operation) applies to the subtree until overridden by another ACI
> (either entry of subtree).

why would you want to change the above semantics (which I agree 
with) when a subtree delete operation is introduced. I dont think you 
should

David

> > > subtreeACI proposal.  At that point in time, then the expired
> > > subtree drafts become interesting because you have a way actually
> > > invoke the subtree operation and apply access control to the
> > > operation.
> > >
> >
> >misunderstood my proposal, I think the separation out of subtree ACI
> >into a separate attribute type is irrelevant to the subtree delete
> >operation.
> >
> >David
> >

David Chadwick

---

From: Ellen Stokes <[email-masked]>
Date: Sun, 23 Jul 2000 20:43:13 -0500

David,
response embedded below.
Ellen

>attributes made no difference at all.

(EJS)  I now see your point.

>with) when a subtree delete operation is introduced. I dont think you

(EJS)  I see your point.

---

From: Ellen Stokes <[email-masked]>
Date: Sun, 23 Jul 2000 22:38:40 -0500

David,

I didn't intend to have different rules here - add and import both
work below as you stated.  I'll change the wording in the permissions
section to reflect this (when I pulled the words from X.500 I guess
I wasn't careful - or should I say perhaps X.500 wasn't careful?).

Ellen

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 25 Jul 2000 08:30:32 -0700

>(EJS)  I now see your point.

A seperate but related issue to how the delete permission overrides the
delete subtree permission, is the more general problems of how to treat
overlapping permissions.  I don't know that there needs to be a general
treatment, but when a new permission that is defined overlaps with a
previously defined permission, there should be some discussion of the
relationship.  Any thoughts?

Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories:
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 25 Jul 2000 19:46:59 +0100

> A seperate but related issue to how the delete permission overrides
> the delete subtree permission, is the more general problems of how to
> treat overlapping permissions.  I don't know that there needs to be a
> general treatment, but when a new permission that is defined overlaps
> with a previously defined permission, there should be some discussion
> of the relationship.  Any thoughts?

The document is already starting to do this by giving precedence to 
the different elements such as subject. Therefore I think that if 
everthing can be given a pecking order/precedence, and this can be 
described fully in the model doc, then everything should fall out in 
the wash, shouldn't it?

David

David Chadwick