Operations require different privileges on different portions of
entries. The following summary applies to primary MDB database
backend. Requirements for other backends may (and often do)
differ.
The add operation requires add (=a) privileges on the pseudo-
attribute entry of the entry being added, and add (=a) privileges
on the pseudo-attribute children of the entry's parent. When
adding the suffix entry of a database, add access to children of
the empty DN ("") is required. Also if Add content ACL checking
has been configured on the database (see the slapd.conf(5) or
slapd-config(5) manual page), add (=a) will be required on all of
the attributes being added.
The bind operation, when credentials are stored in the directory,
requires auth (=x) privileges on the attribute the credentials
are stored in (usually userPassword).
The compare operation requires compare (=c) privileges on the
attribute that is being compared.
The delete operation requires delete (=z) privileges on the
pseudo-attribute entry of the entry being deleted, and delete
(=d) privileges on the children pseudo-attribute of the entry's
parent.
The modify operation requires write (=w) privileges on the
attributes being modified. In detail, add (=a) is required to
add new values, delete (=z) is required to delete existing
values, and both delete and add (=az), or write (=w), are
required to replace existing values.
The modrdn operation requires write (=w) privileges on the
pseudo-attribute entry of the entry whose relative DN is being
modified, delete (=z) privileges on the pseudo-attribute children
of the old entry's parents, add (=a) privileges on the pseudo-
attribute children of the new entry's parents, and add (=a)
privileges on the attributes that are present in the new relative
DN. Delete (=z) privileges are also required on the attributes
that are present in the old relative DN if deleteoldrdn is set to
1.
The search operation, requires search (=s) privileges on the
entry pseudo-attribute of the searchBase (NOTE: this was
introduced with OpenLDAP 2.4). Then, for each entry, it requires
search (=s) privileges on the attributes that are defined in the
filter. The resulting entries are finally tested for read (=r)
privileges on the pseudo-attribute entry (for read access to the
entry itself) and for read (=r) access on each value of each
attribute that is requested. Also, for each referral object used
in generating continuation references, the operation requires
read (=r) access on the pseudo-attribute entry (for read access
to the referral object itself), as well as read (=r) access to
the attribute holding the referral information (generally the ref
attribute).
Some internal operations and some controls require specific
access privileges.
The SASL authzID mapping and the LDAP proxyAuthz control require
auth (=x) privileges on all the attributes that are present in
the search filter of the URI regexp maps (the right-hand side of
the authz-regexp directives). Auth (=x) privileges are also
required on the authzTo attribute of the authorizing identity
and/or on the authzFrom attribute of the authorized identity. In
both cases, it is the authorizing identity that requires the
privileges (i.e. the identity that has authenticated and is now
trying to do some operation using another entity's permissions).
In general, when an internal lookup is performed for
authentication or authorization purposes, search-specific
privileges (see the access requirements for the search operation
illustrated above) are relaxed to auth.
Access control to search entries is checked by the frontend, so
it is fully honored by all backends; for all other operations and
for the discovery phase of the search operation, full ACL
semantics is only supported by the primary backends, i.e.
slapd-mdb(5).
Some other backend, like slapd-sql(5), may fully support them;
others may only support a portion of the described semantics, or
even differ in some aspects. The relevant details are described
in the backend-specific man pages.
