Re: More granular privileges in ACLs (Was: (ITS#3625) [enhancement] per-operation ACLs)

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

I think we need to be careful of too fine of privileges.  The
distinctions will become to subtle for folks to grasp, and
unnecessarily complex to implement.

While it seems to me that all we need to do is divide write
into add and delete, doing that is somewhat problematic when
you consider modify/replace.  Having finer grainer permissions
may lead to a need to do the permission check with knowledge
of the entry's contents and the effect of the modify/replace.
Today that the check is done without regard to the entry's
contents, I suggest it stay that way.  Can we live with
modify/replace with no values requiring delete permission
and modify/replace with values requiring both delete and add
permissions.

I see that you talk of both value and entry permissions.
We already have separation of entry add/delete from attribute
add/delete from value add/delete.  I don't think we need
another way to distinguish entry v. attribute v. value
permissions.

I see no reason to split "manage" (manage the DSA IT), at
least not yet.

Also, "auth" means permission to use information in authentication
and authorization processes.  It is neither a permission to
authenticate nor permission to assume an identity.  Of course,
not having permission to use a piece of information in authentication
and authorization process can lead to permission not being granted
for these or other actions.  I don't see any particular need to
split it.

Now, one area not discussed here is the separation of real and
effective permissions.  That is, at present, we do everything
based on the user's effective authorization identity.  It would
be nice to base decisions on the user's real authorization
identity as well.  Howard and I bounced around some ideas in this
area (namely adding realdn, realself, realgroup by parameters,
or the like).

Kurt

At 05:15 AM 4/2/2005, Pierangelo Masarati wrote:
>[moved to -devel from ITS#3625]
>
>ando@sys-net.it wrote:
>
>>without any intention to revitalize the <draft-ietf-ldapext-acl-model>, to fulfil the requirement of this ITS we should at least borrow some of its concepts.  I note that our (d) borrows (and may partially extend) the "t: returnDN" privilege of that draft, while our (m) is not paralleled, at least in the broad (and loose) meaning we're discussing, like allowing the structuralObjectClass to be changed and so.
>>
>>There's a lot of granularity we may want to borrow (perhaps too much) in
>>
>>Permissions which apply to attributes:
>>
>>      ...
>>  w   Write       Modify-add values
>>  o   Obliterate  Modify-delete values
>> 
>we could argue on what permissions are reuired by a modification that replaces or increments values; I'd require both Write and Obliterate.
>
>>      ...
>>  m   Make        Make attributes on a new entry below
>>                    this entry
>>
>>and in
>>
>>  a    Add        Add an entry below this entry
>>  d    Delete     Delete this entry
>>  e    Export     Export entry & subordinates to new
>>                     location
>>  i    Import     Import entry & subordinates from some
>>                     location
>>  n    RenameDN   Rename an entry's DN
>>
>>I think the "i: Import" and "e: Export" are a (perhaps excessive) granularization of (m) manage, yet some extra management granularity and generality is missing to account for other non-user allowed internal operations.
>>
>>Finally, the granular options should be logically grouped under the umbrella of the current OpenLDAP privileges, to ease transition and in general configuration whenever grnularity is not needed.
>>
>>So (using the extended names to avoid confision):
>>
>>OpenLDAP            draft-ietf-ldapext-acl-model
>>disclose            returnDN (and more)
>>auth                n.a.
>>search              Search
>>compare             Compare
>>read                Read, BrowseDN
>>write               Write, Obliterate, Make, Add, Delete, RenameDN
>>manage              Export, Import (and more)
>> 
>Suggestion: use current names and abbreviations semantics for OpenLDAP-style access; use draft-ietf-ldapext-acl-model abbreviations, uppercased, for granular, selective permissions only in {+|-|=}{0dxscrwmTSCRBADNWOMEI} mode.
>At this point, we may well find some room for the (p) proxy permission Howard was suggesting some time ago; the "proxy" privilege could be a granular specialization of "auth", e.g. authentication and proxying have the same level; "auth" (x) implies both;  (X) indicates "authc" and (P) indicates "authz".
>
>disclose   (d) == (T)
>auth       (x) == (XP)
>search     (s) == (S)
>compare    (c) == (C)
>read       (r) == (RB)
>write      (w) == (ADNWOM)
>manage     (m) == (EI) and more
>
>Since they're a mere duplication, (T), (S) and (C) could be dropped; however, I'd keep them in place because in the future we might want to add granularity to those levels as well; in that case, the above values would preserve their current meaning, and some other values may be dedicated to the new functionality.
>With respect to the "browse" (B) privilege, slapd currently implements it by means of the "read" (r) privilege applied to the "entry" pseudo-attribute, it's not an issue; I'd add it for completeness (unless it only adds confusion).
>
>>If there's consensus on implementing all (or some) of these, and on the grouping I can (fast?)prototype an implementation.
>> 
>p.
>
>
>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497