Re: delete permission

["David Chadwick" <d.w.chadwick@salford.ac.uk>]

Date forwarded: 	Fri, 21 Jul 2000 07:46:37 -0700 (PDT)
Date sent:      	Fri, 21 Jul 2000 09:45:20 -0500
To:             	d.w.chadwick@salford.ac.uk, bgreenblatt@directory-applications.com
From:           	Ellen Stokes <stokes@austin.ibm.com>
Subject:        	Re: delete permission
Copies to:      	ietf-ldapext@netscape.com
Forwarded by:   	ietf-ldapext@netscape.com

> 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.

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.

> 
> 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).

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

> 
> Ellen
> 
> 
> 
> At 10:24 PM 7/20/00 +0100, David Chadwick wrote:
> >Date sent:              Tue, 18 Jul 2000 16:55:52 -0500
> >To:                     d.w.chadwick@salford.ac.uk,
> >ietf-ldapext@netscape.com,
> >         bgreenblatt@directory-applications.com
> >From:                   Ellen Stokes <stokes@austin.ibm.com>
> >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
> >
> > >
> > > 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.
> > >
> >
> >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
> >IS Institute, University of Salford, Salford M5 4WT
> >Tel +44 161 295 5351  Fax +44 161 745 8169
> >Mobile +44 790 167 0359
> >Email D.W.Chadwick@salford.ac.uk
> >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
> >
> >***************************************************
> 
> 


***************************************************

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 D.W.Chadwick@salford.ac.uk
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

***************************************************