[Date Prev][Date Next] [Chronological] [Thread] [Top]

SV: application defined permissions

Hello LDAPext!

So I decided to join the list and that was easy. What could be done using the list? Not so easy.

No, I haven't read through the entire archive but if not me who, if not now when.

Here we go.

The problem of defining permission seems to be a problem of demarcation and since the days of von Neuman demarcating state machines is done demarcating data and/or operations. Permissions is data that imply specific operations so demarcating permissions means demarcating operations. Is there anyone that of today could define all operations in future LDAP use? So we could discuss leaving the door open using "application defined definitions" but what about the possibility of interference between permissions application defined or not. It's my belief that extending permissions isn't about defining them by lists but to define a few basic permissions (read, write, create and delete) and expressing all future permissions in terms of these basic permissions. All future permissions must be decomposable into the basic permissions and interference between future permissions is resolved by interference rules among the basic permissions.

There should be an example here but I'm too tired so 

sweet dreams
Per-Olav
Sleepyhead

P.S. All symantic ;-) or semantic errors are intentional and created in communication of this message to you. D.S.

-----Ursprungligt meddelande-----
Från: Kurt D. Zeilenga <Kurt@OpenLDAP.org>
Till: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Kopia: ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>; ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>
Datum: den 20 februari 2001 20:21
Ämne: Re: application defined permissions


>At 11:00 AM 2/20/01 -0800, Bruce Greenblatt wrote:
>>At 10:54 AM 2/20/2001 -0800, Kurt D. Zeilenga wrote:
>>>An attribute type can not, should not be both userApplication and
>>>operational usages.
>>
>>Why not?
>
>Because a directory implementation may not implement the operational
>usage but your application should still be able to store the user
>value.  A server which does not support the operational usage should
>not publish the ldapACI attribute in its subschema.
>
>Kurt
>