Subject: SV: application defined permissions

From: "Per-Olav Gramstad" <[email-masked]>
Date: Wed, 21 Feb 2001 01:13:18 +0100

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 <[email-masked]>
Till: Bruce Greenblatt <[email-masked]>
Kopia: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 20 Feb 2001 17:15:44 -0800

>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 th…

Please note the distinction between "application defined permissions"
and "permissions to control access to extended operations".  The former
would be held by the server, but never be used by the server. The
latter would provide some form of extensibility to control access
in not-yet-defined operations.

Now, in regards to your general suggestion to control extensions
in terms of current permissions, I basically concur.  However,
there are extensions which don't fit well into the base
permission set.

Hence, I support adding some means of extending permissions to
support extended operations but do not support using ldapACI
for holding access information which does not controlling any
LDAP operations.