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

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

[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
  i    Import     Import entry & subordinates from some
  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.


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497