.SH THE ACCESS DIRECTIVE
The structure of the access control directives is
.TP
-.B access to <what> "[ by <who> <access> [ <control> ] ]+"
+.B access to <what> "[ by <who> [ <access> ] [ <control> ] ]+"
Grant access (specified by
.BR <access> )
to a set of entries and/or attributes (specified by
.BR <what> )
by one or more requestors (specified by
.BR <who> ).
+
+.LP
+Lists of access directives are evaluated in the order they appear
+in \fIslapd.conf\fP.
+When a
+.B <what>
+clause matches the datum whose access is being evaluated, its
+.B <who>
+clause list is checked.
+When a
+.B <who>
+clause matches the accessor's properties, its
+.B <access>
+and
+.B <control>
+clauses are evaluated.
+Access control checking stops at the first match of the
+.B <what>
+and
+.B <who>
+clause, unless otherwise dictated by the
+.B <control>
+clause.
+Each
+.B <who>
+clause list is implicitly terminated by a
+.LP
+.nf
+ by * none stop
+.fi
+.LP
+clause that results in stopping the access control with no access
+privileges granted.
+Each
+.B <what>
+clause list is implicitly terminated by a
+.LP
+.nf
+ access to *
+ by * none
+.fi
+.LP
+clause that results in granting no access privileges to an otherwise
+unspecified datum.
.SH THE <WHAT> FIELD
The field
.BR <what>
It can have the forms
.LP
.nf
- [dn[.<dnstyle>]=]<dnpattern>
+ dn[.<dnstyle>]=<dnpattern>
filter=<ldapfilter>
attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
.fi
The statement
.B dn=<dnpattern>
selects the entries based on their naming context.
-The
-.B dn=
-part is optional.
The
.B <dnpattern>
is a string representation of the entry's DN.
.LP
The
.B <dnstyle>
-is also optional; however, it is recommended to specify both the
-.B dn=
-and the
-.B <dnstyle>
-to avoid ambiguities.
+is optional; however, it is recommended to specify it to avoid ambiguities.
.B Base
(synonym of
.BR baseObject ),
.LP
The statement
.B filter=<ldapfilter>
-selects the entries based on a valid LDAP filter as described in RFC 2254.
+selects the entries based on a valid LDAP filter as described in RFC 4515.
A filter of
.B (objectClass=*)
is implied if no
tls_ssf=<n>
sasl_ssf=<n>
- aci[=<attrname>]
- dynacl/name[/<options>][.<dynstyle>][=<pattern>]
+ dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
.fi
.LP
with
<domainstyle>={exact|regex|sub(tree)}
<setstyle>={exact|regex}
<modifier>={expand}
+ <name>=aci <pattern>=<attrname>]
.fi
.LP
They may be specified in combination.
is undocumented yet.
.LP
The statement
-.B aci[=<attrname>]
-means that the access control is determined by the values in the
-.B attrname
-of the entry itself.
-The optional
-.B <attrname>
-indicates what attributeType holds the ACI information in the entry.
-By default, the
-.B OpenLDAPaci
-operational attribute is used.
-ACIs are experimental; they must be enabled at compile time.
-.LP
-The statement
.B dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
means that access checking is delegated to the admin-defined method
indicated by
.B <pattern>
are optional, and are directly passed to the registered parsing routine.
Dynacl is experimental; it must be enabled at compile time.
-If dynacl and ACIs are both enabled, ACIs are cast into the dynacl scheme,
-where
-.B <name>=aci
-and, optionally,
-.BR <patten>=<attrname> .
-However, the original ACI syntax is preserved for backward compatibility.
+.LP
+The statement
+.B dynacl/aci[=<attrname>]
+means that the access control is determined by the values in the
+.B attrname
+of the entry itself.
+The optional
+.B <attrname>
+indicates what attributeType holds the ACI information in the entry.
+By default, the
+.B OpenLDAPaci
+operational attribute is used.
+ACIs are experimental; they must be enabled at compile time.
.LP
The statements
.BR ssf=<n> ,
set the minimum required Security Strength Factor (ssf) needed
to grant access. The value should be positive integer.
.SH THE <ACCESS> FIELD
-The field
+The optional field
.B <access> ::= [[real]self]{<level>|<priv>}
determines the access level or the specific access privileges the
.B who
Its component are defined as
.LP
.nf
- <level> ::= none|disclose|auth|compare|search|read|write
- <priv> ::= {=|+|-}{w|r|s|c|x|d|0}+
+ <level> ::= none|disclose|auth|compare|search|read|write|manage
+ <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
.fi
.LP
The modifier
and
.BR write .
Each access level implies all the preceding ones, thus
-.B write
-access will imply all accesses.
+.B manage
+grants all access including administrative access,
.LP
The
.B none
.B -
signs add/remove access privileges to the existing ones.
The privileges are
+.B m
+for manage,
.B w
for write,
.B r
More than one of the above privileges can be added in one statement.
.B 0
indicates no privileges and is used only by itself (e.g., +0).
+.LP
If no access is given, it defaults to
.BR +0 .
.SH THE <CONTROL> FIELD
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 LDBM, BDB, and HDB backends. Requirements for other backends may
+the BDB and HDB backends. Requirements for other backends may
(and often do) differ.
+
.LP
The
.B add
privileges on the pseudo-attribute
.B children
of the entry's parent.
+When adding the suffix entry of a database, write access to
+.B children
+of the empty DN ("") is required.
+
.LP
The
.B bind
.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
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.
+
.LP
The
.B modrdn
in the old relative DN if
.B deleteoldrdn
is set to 1.
+
.LP
The
.B search
(generally the
.B ref
attribute).
+
.LP
Some internal operations and some
.B controls
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),
-.BR back-hdb (5),
and
-.BR back-ldbm (5).
+.BR back-hdb (5).
Some other backend, like
.BR back-sql (5),