+.LP
+One useful application is to easily grant write privileges to an
+.B updatedn
+that is different from the
+.BR rootdn .
+In this case, since the
+.B updatedn
+needs write access to (almost) all data, one can use
+.LP
+.nf
+ access to *
+ by dn.exact="cn=The Update DN,dc=example,dc=com" write
+ by * break
+.fi
+.LP
+as the first access rule.
+As a consequence, unless the operation is performed with the
+.B updatedn
+identity, control is passed straight to the subsequent rules.
+
+.SH OPERATION REQUIREMENTS
+Operations require different privileges on different portions of entries.
+The following summary applies to primary database backends such as
+the BDB and HDB backends. Requirements for other backends may
+(and often do) differ.
+
+.LP
+The
+.B add
+operation requires
+.B add (=a)
+privileges on the pseudo-attribute
+.B entry
+of the entry being added, and
+.B add (=a)
+privileges on the pseudo-attribute
+.B children
+of the entry's parent.
+When adding the suffix entry of a database,
+.B add
+access to
+.B children
+of the empty DN ("") is required. Also if
+Add content ACL checking has been configured on
+the database (see the
+.BR slapd.conf (5)
+or
+.BR slapd\-config (5)
+manual page),
+.B add (=a)
+will be required on all of the attributes being added.
+
+.LP
+The
+.B bind
+operation, when credentials are stored in the directory, requires
+.B auth (=x)
+privileges on the attribute the credentials are stored in (usually
+.BR userPassword ).
+
+.LP
+The
+.B compare
+operation requires
+.B compare (=c)
+privileges on the attribute that is being compared.
+
+.LP
+The
+.B delete
+operation requires
+.B delete (=z)
+privileges on the pseudo-attribute
+.B entry
+of the entry being deleted, and
+.B delete (=d)
+privileges on the
+.B children
+pseudo-attribute of the entry's parent.
+
+.LP
+The
+.B modify
+operation requires
+.B write (=w)
+privileges on the attributes being modified.
+In detail,
+.B add (=a)
+is required to add new values,
+.B delete (=z)
+is required to delete existing values,
+and both
+.B delete
+and
+.BR "add (=az)" ,
+or
+.BR "write (=w)" ,
+are required to replace existing values.
+
+.LP
+The
+.B modrdn
+operation requires
+.B write (=w)
+privileges on the pseudo-attribute
+.B entry
+of the entry whose relative DN is being modified,
+.B delete (=z)
+privileges on the pseudo-attribute
+.B children
+of the old entry's parents,
+.B add (=a)
+privileges on the pseudo-attribute
+.B children
+of the new entry's parents, and
+.B add (=a)
+privileges on the attributes that are present in the new relative DN.
+.B Delete (=z)
+privileges are also required on the attributes that are present
+in the old relative DN if
+.B deleteoldrdn
+is set to 1.
+
+.LP
+The
+.B search
+operation, requires
+.B search (=s)
+privileges on the
+.B entry
+pseudo-attribute of the searchBase
+(NOTE: this was introduced with OpenLDAP 2.4).
+Then, for each entry, it requires
+.B search (=s)
+privileges on the attributes that are defined in the filter.
+The resulting entries are finally tested for
+.B read (=r)
+privileges on the pseudo-attribute
+.B entry
+(for read access to the entry itself)
+and for
+.B read (=r)
+access on each value of each attribute that is requested.
+Also, for each
+.B referral
+object used in generating continuation references, the operation requires
+.B read (=r)
+access on the pseudo-attribute
+.B entry
+(for read access to the referral object itself),
+as well as
+.B read (=r)
+access to the attribute holding the referral information
+(generally the
+.B ref
+attribute).
+
+.LP
+Some internal operations and some
+.B controls
+require specific access privileges.
+The
+.B authzID
+mapping and the
+.B proxyAuthz
+control require
+.B 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
+.B authz-regexp
+directives).
+.B Auth (=x)
+privileges are also required on the
+.B authzTo
+attribute of the authorizing identity and/or on the
+.B authzFrom
+attribute of the authorized identity.
+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
+.BR auth .
+
+.LP
+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.
+.BR back\-bdb (5),
+and
+.BR back\-hdb (5).
+
+Some other backend, like
+.BR back\-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.
+
+.SH CAVEATS
+It is strongly recommended to explicitly use the most appropriate
+.B <dnstyle>
+in
+.B <what>
+and
+.B <who>
+clauses, to avoid possible incorrect specifications of the access rules
+as well as for performance (avoid unnecessary regex matching when an exact
+match suffices) reasons.
+.LP
+An administrator might create a rule of the form:
+.LP
+.nf
+ access to dn.regex="dc=example,dc=com"
+ by ...
+.fi
+.LP
+expecting it to match all entries in the subtree "dc=example,dc=com".
+However, this rule actually matches any DN which contains anywhere
+the substring "dc=example,dc=com". That is, the rule matches both
+"uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
+.LP
+To match the desired subtree, the rule would be more precisely
+written:
+.LP
+.nf
+ access to dn.regex="^(.+,)?dc=example,dc=com$"
+ by ...
+.fi
+.LP
+For performance reasons, it would be better to use the subtree style.
+.LP
+.nf
+ access to dn.subtree="dc=example,dc=com"
+ by ...
+.fi
+.LP
+When writing submatch rules, it may be convenient to avoid unnecessary
+.B regex
+.B <dnstyle>
+use; for instance, to allow access to the subtree of the user
+that matches the
+.B <what>
+clause, one could use
+.LP
+.nf
+ access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
+ by dn.regex="^uid=$2,dc=example,dc=com$$" write
+ by ...
+.fi
+.LP
+However, since all that is required in the
+.B <by>
+clause is substring expansion, a more efficient solution is
+.LP
+.nf
+ access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
+ by dn.exact,expand="uid=$2,dc=example,dc=com" write
+ by ...
+.fi
+.LP
+In fact, while a
+.B <dnstyle>
+of
+.B regex
+implies substring expansion,
+.BR exact ,
+as well as all the other DN specific
+.B <dnstyle>
+values, does not, so it must be explicitly requested.
+.LP