Re: Empty rights list in draft-ietf-ldapext-acl-model-04.txt

[David Ward <DSWARD@novell.com>]

If the only intent was to provide a condensed string that said 'no permissions', I would suggest this option be removed.  As your example points out, there are already multiple ways to achieve the same result.  In this case I think less is better.  

Also since ACL storage is server dependent, implementors are free to condense the acl strings any way they want.

David

>>> <djbyrne@us.ibm.com> 10/20/99 11:54:37 AM >>>




David,

I believe Ellen meant to say that we need to have a defined method of stating
explicit denial independent of how the server stores the information. Acl
storage is definitely going to be server dependent; the goal is to have an
agreed upon behavior regardless of the storage.

Part of the wording of the original paragraph is out of date now, since we have
agreed to have deny take precedence over grant, and that  deny is the default. I
think all of the following statements now essentially state the same thing:
Don't allow any permissions to Dept XYZ

1.  aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US

2. aci: 1.2.3.4#subtree#deny;r,w,s,c;[all]#group#cn=Dept XYZ, c=US
   aci: 1.2.3.4#subtree#deny;a,d,e;[entry]#group#cn=Dept XYZ, c=US

3. aci: 1.2.3.4#subtree#grant;;[all]#group#cn=Dept XYZ, c=US
   aci: 1.2.3.4#subtree#grant;;[entry]#group#cn=Dept XYZ, c=US

4. aci: 1.2.3.4#subtree#grant;;[all]$grant;;[entry]#group#cn=Dept XYZ, c=US

Back to the original question of why support format #1; The intent was for a
condensed string that said 'no permissions'.

Debbie


"David Ward" <DSWARD@novell.com> on 10/19/99 11:01:18 AM

I'm a bit confused.  There is already a way to express explicit denial and it
doesn't require support for an empty rights list.  An example would be:

 aci: 1.2.3.4#subtree#deny;r,w,s,c;[all]#group#cn=Dept XYZ, c=US
 aci: 1.2.3.4#subtree#deny;a,d,e;[entry]#group#cn=Dept XYZ, c=US

Or I guess you could do the revervse and grant nothing:

 aci: 1.2.3.4#subtree#grant;;[all]#group#cn=Dept XYZ, c=US
 aci: 1.2.3.4#subtree#grant;;[entry]#group#cn=Dept XYZ, c=US

I am not sure what you mean by " explicit denial where it is server dependent on
exactly how that server stores it"?  Section 2, second paragraph from the
bottom, states "No mechanisms are defined ... for storage of access control
information at the server; this is vendor dependent".  If I understand this
correctly, the storage method is already server dependent.

David

>>> Ellen Stokes <stokes@austin.ibm.com> 10/19/99 4:21:21 AM >>>
It was a mistake to say that the interpretation of an empty rights ACI is
server
dependent.  We need to be able to express a way of stating 'explicit
denial' where
it is server dependent on exactly how that server stores it.  So an empty
rights
field is permissible and means 'deny all rights to that subject'.  I'll fix
the draft
to correctly reflect this.
Ellen

At 04:45 PM 10/12/1999 -0600, David Ward wrote:
>The BNF in section 6.1 defines rights as:
>
>          < rights > ::= [  ]   |   [ < right > + [ '$'
>                         + <right> ] * ]
>
>This allows the rights part of the acl entry syntax to be empty and
section 6.3 gives an example of an empty rights ACI:
>
>             aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
>
>It goes on to say the interpretation of an empty rights ACI is server
dependent.  What is the purpose and/or value of allowing this type of ACI?
If the interpretation of grant or deny is server dependent, it surely can't
promote interoperability between ldap server vendors.
>
>David
>
>