Re: SV: application defined permissions

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:13 AM 2/21/01 +0100, Per-Olav Gramstad wrote:
>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.

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.