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

[Pierangelo Masarati <ando@sys-net.it>]

[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