X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=doc%2Fman%2Fman5%2Fslapd.access.5;h=0b11805952ad1cf409ad4c948f1b93c538198aec;hb=c8c34cdd43d3603f3b64a56841b4425379c98f45;hp=8e48197957a7501d67d124806d0fbab519dc7a21;hpb=947f41832ee6f0cd925560ebbe7c67daf8a4fa87;p=openldap

diff --git a/doc/man/man5/slapd.access.5 b/doc/man/man5/slapd.access.5
index 8e48197957..0b11805952 100644
--- a/doc/man/man5/slapd.access.5
+++ b/doc/man/man5/slapd.access.5
@@ -1,6 +1,7 @@
 .TH SLAPD.ACCESS 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 1998-2003 The OpenLDAP Foundation All Rights Reserved.
+.\" Copyright 1998-2011 The OpenLDAP Foundation All Rights Reserved.
 .\" Copying restrictions apply.  See COPYRIGHT/LICENSE.
+.\" $OpenLDAP$
 .SH NAME
 slapd.access \- access configuration for slapd, the stand-alone LDAP daemon
 .SH SYNOPSIS
@@ -10,13 +11,15 @@ The
 .BR slapd.conf (5)
 file contains configuration information for the
 .BR slapd (8)
-daemon. This configuration file is also used by the
-.BR slurpd (8)
-replication daemon and by the SLAPD tools
+daemon. This configuration file is also used by the SLAPD tools
+.BR slapacl (8),
 .BR slapadd (8),
+.BR slapauth (8),
 .BR slapcat (8),
+.BR slapdn (8),
+.BR slapindex (8),
 and
-.BR slapindex (8).
+.BR slaptest (8).
 .LP
 The
 .B slapd.conf
@@ -48,22 +51,78 @@ directives are defined for a backend or those which are defined are
 not applicable, the directives from the global configuration section
 are then used.
 .LP
+If no access controls are present, the default policy
+allows anyone and everyone to read anything but restricts
+updates to rootdn.  (e.g., "access to * by * read").
+.LP
+When dealing with an access list, because the global access list is 
+effectively appended to each per-database list, if the resulting 
+list is non-empty then the access list will end with an implicit 
+.B access to * by * none
+directive. If there are no access directives applicable to a backend, 
+then a default read is used.
+.LP
+.B Be warned: the rootdn can always read and write EVERYTHING!
+.LP
 For entries not held in any backend (such as a root DSE), the
-directives of the first backend (and any global directives) are
-used.
+global directives are used.
 .LP
 Arguments that should be replaced by actual text are shown in
 brackets <>.
 .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>
@@ -71,48 +130,82 @@ specifies the entity the access control directive applies to.
 It can have the forms
 .LP
 .nf
-	*
-	[dn[.<dnstyle>]=<DN>] 
-	[filter=<ldapfilter>]
-	[attrs=<attrlist>[ val[.<style>]=<attrval>]]
+	dn[.<dnstyle>]=<dnpattern>
+	filter=<ldapfilter>
+	attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
 .fi
 .LP
-The wildcard
-.B *
-stands for all the entries.
+with
+.LP
+.nf
+	<dnstyle>={{exact|base(object)}|regex
+		|one(level)|sub(tree)|children}
+	<attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
+	<attrstyle>={{exact|base(object)}|regex
+		|one(level)|sub(tree)|children}
+.fi
 .LP
 The statement
-.B dn=<DN>
+.B dn=<dnpattern>
 selects the entries based on their naming context.
-The pattern is a string representation of the entry's DN.
-.BR base ,
+The
+.B <dnpattern>
+is a string representation of the entry's DN.
+The wildcard
+.B *
+stands for all the entries, and it is implied if no
+.B dn
+form is given.
+.LP
+The 
+.B <dnstyle> 
+is optional; however, it is recommended to specify it to avoid ambiguities.
+.B Base 
+(synonym of
+.BR baseObject ),
 the default,
 or
 .B exact 
 (an alias of 
 .BR base )
-indicates the entry whose DN is equal to the pattern.
+indicates the entry whose DN is equal to the
+.BR <dnpattern> ;
 .B one
+(synonym of
+.BR onelevel )
 indicates all the entries immediately below the
-.BR pattern ,
-.B subtree
-indicates all entries in the subtree at the pattern,
+.BR <dnpattern> ,
+.B sub
+(synonym of
+.BR subtree )
+indicates all entries in the subtree at the
+.BR <dnpattern> ,
 .B children
-indicates all the entries below (subordinate to) the pattern.
+indicates all the entries below (subordinate to) the 
+.BR <dnpattern> .
 .LP
 If the
 .B <dnstyle>
 qualifier is
 .BR regex ,
-then the value is a regular expression pattern,
+then 
+.B <dnpattern>
+is a POSIX (''extended'') regular expression pattern,
 as detailed in
-.BR regex (7),
+.BR regex (7)
+and/or
+.BR re_format (7),
 matching a normalized string representation of the entry's DN.
 The regex form of the pattern does not (yet) support UTF-8.
 .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
+.B filter
+form is given.
 .LP
 The statement
 .B attrs=<attrlist>
@@ -127,33 +220,32 @@ are required and/or allowed by that objectClass.
 Actually, names in 
 .B <attrlist>
 that are prefixed by
-.B +
-are directly treated as objectClass names, while names that 
-do not correspond to an attribute type are also searched 
-in the objectclass set.
-This latter behavior is deprecated and might not be supported
-in future releases.
-A name prefixed by
+.B @
+are directly treated as objectClass names.  A name prefixed by
 .B !
 is also treated as an objectClass, but in this case the access rule
 affects the attributes that are not required nor allowed 
 by that objectClass.
+If no
+.B attrs
+form is given, 
+.B attrs=@extensibleObject
+is implied, i.e. all attributes are addressed.
 .LP
 Using the form
-.B attrs=<attr> val[.<style>]=<value>
+.B attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
 specifies access to a particular value of a single attribute.
-In this case, only a single attribute type may be given. A value
-.B <style>
-of
+In this case, only a single attribute type may be given. The
+.B <attrstyle>
 .B exact
 (the default) uses the attribute's equality matching rule to compare the
-value. If the value
-.B <style>
+value, unless a different (and compatible) matching rule is specified. If the
+.B <attrstyle>
 is
 .BR regex ,
-the provided value is used as a regular expression pattern.
-If the attribute has DN syntax, the value
-.B <style>
+the provided value is used as a POSIX (''extended'') regular
+expression pattern.  If the attribute has DN syntax, the 
+.B <attrstyle>
 can be any of
 .BR base ,
 .BR onelevel ,
@@ -165,6 +257,24 @@ resulting in base, onelevel, subtree or children match, respectively.
 The dn, filter, and attrs statements are additive; they can be used in sequence 
 to select entities the access rule applies to based on naming context,
 value and attribute type simultaneously.
+Submatches resulting from
+.B regex
+matching can be dereferenced in the
+.B <who>
+field using the syntax
+.IR ${v<n>} ,
+where
+.I <n>
+is the submatch number.
+The default syntax,
+.IR $<n> ,
+is actually an alias for
+.IR ${d<n>} ,
+that corresponds to dereferencing submatches from the
+.B dnpattern
+portion of the
+.B <what>
+field.
 .SH THE <WHO> FIELD
 The field
 .B <who>
@@ -180,24 +290,47 @@ It can have the forms
 	*
 	anonymous
 	users
-	self
+	self[.<selfstyle>]
 
 	dn[.<dnstyle>[,<modifier>]]=<DN>
 	dnattr=<attrname>
+
+	realanonymous
+	realusers
+	realself[.<selfstyle>]
+
+	realdn[.<dnstyle>[,<modifier>]]=<DN>
+	realdnattr=<attrname>
+
 	group[/<objectclass>[/<attrname>]]
-		[.<style>]=<group>
-	peername[.<style>]=<peername>
+		[.<groupstyle>]=<group>
+	peername[.<peernamestyle>]=<peername>
 	sockname[.<style>]=<sockname>
 	domain[.<domainstyle>[,<modifier>]]=<domain>
 	sockurl[.<style>]=<sockurl>
-	set[.<style>]=<pattern>
+	set[.<setstyle>]=<pattern>
 
 	ssf=<n>
 	transport_ssf=<n>
 	tls_ssf=<n>
 	sasl_ssf=<n>
 
-	aci=<attrname>
+	dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
+.fi
+.LP
+with
+.LP
+.nf
+	<style>={exact|regex|expand}
+	<selfstyle>={level{<n>}}
+	<dnstyle>={{exact|base(object)}|regex
+		|one(level)|sub(tree)|children|level{<n>}}
+	<groupstyle>={exact|expand}
+	<peernamestyle>={<style>|ip|ipv6|path}
+	<domainstyle>={exact|regex|sub(tree)}
+	<setstyle>={exact|expand}
+	<modifier>={expand}
+	<name>=aci		<pattern>=<attrname>]
 .fi
 .LP
 They may be specified in combination.
@@ -209,6 +342,11 @@ The wildcard
 .B *
 refers to everybody.
 .LP
+The keywords prefixed by
+.B real
+act as their counterparts without prefix; the checking respectively occurs
+with the \fIauthentication\fP DN and the \fIauthorization\fP DN.
+.LP
 The keyword
 .B anonymous
 means access is granted to unauthenticated clients; it is mostly used 
@@ -224,6 +362,18 @@ The keyword
 .B self
 means access to an entry is allowed to the entry itself (e.g. the entry
 being accessed and the requesting entry must be the same).
+It allows the 
+.B level{<n>}
+style, where \fI<n>\fP indicates what ancestor of the DN 
+is to be used in matches.
+A positive value indicates that the <n>-th ancestor of the user's DN
+is to be considered; a negative value indicates that the <n>-th ancestor
+of the target is to be considered.
+For example, a "\fIby self.level{1} ...\fP" clause would match
+when the object "\fIdc=example,dc=com\fP" is accessed
+by "\fIcn=User,dc=example,dc=com\fP".
+A "\fIby self.level{-1} ...\fP" clause would match when the same user
+accesses the object "\fIou=Address Book,cn=User,dc=example,dc=com\fP".
 .LP
 The statement
 .B dn=<DN>
@@ -240,7 +390,23 @@ dn.regex clause by using the form
 .BR $<digit> ,
 with 
 .B digit
-ranging from 1 to 9.
+ranging from 0 to 9 (where 0 matches the entire string),
+or the form
+.BR ${<digit>+} ,
+for submatches higher than 9.
+Substring substitution from attribute value can
+be done in 
+using the form
+.BR ${v<digit>+} .
+Since the dollar character is used to indicate a substring replacement,
+the dollar character that is used to indicate match up to the end of
+the string must be escaped by a second dollar character, e.g.
+.LP
+.nf
+    access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
+        by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
+.fi
+.LP
 The style qualifier
 allows an optional
 .BR modifier .
@@ -251,6 +417,84 @@ even if
 .B dnstyle
 is not 
 .BR regex .
+Note that the 
+.B regex 
+dnstyle in the above example may be of use only if the 
+.B <by>
+clause needs to be a regex; otherwise, if the
+value of the second (from the right)
+.B dc=
+portion of the DN in the above example were fixed, the form
+.LP
+.nf
+    access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
+        by dn.exact,expand="uid=$2,dc=example,dc=com" write
+.fi
+.LP
+could be used; if it had to match the value in the 
+.B <what>
+clause, the form
+.LP
+.nf
+    access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
+        by dn.exact,expand="uid=$2,dc=$3,dc=com" write
+.fi
+.LP
+could be used.
+.LP
+Forms of the 
+.B <what>
+clause other than regex may provide submatches as well.
+The 
+.BR base(object) ,
+the
+.BR sub(tree) ,
+the
+.BR one(level) ,
+and the
+.BR children
+forms provide
+.B $0
+as the match of the entire string.
+The 
+.BR sub(tree) ,
+the
+.BR one(level) ,
+and the
+.BR children
+forms also provide
+.B $1
+as the match of the rightmost part of the DN as defined in the
+.B <what>
+clause.
+This may be useful, for instance, to provide access to all the 
+ancestors of a user by defining
+.LP
+.nf
+    access to dn.subtree="dc=com"
+        by dn.subtree,expand="$1" read
+.fi
+.LP
+which means that only access to entries that appear in the DN of the
+.B <by>
+clause is allowed.
+.LP
+The 
+.BR level{<n>}
+form is an extension and a generalization of the
+.BR onelevel
+form, which matches all DNs whose <n>-th ancestor is the pattern.
+So, \fIlevel{1}\fP is equivalent to \fIonelevel\fP, 
+and \fIlevel{0}\fP is equivalent to \fIbase\fP.
+.LP
+It is perfectly useless to give any access privileges to a DN 
+that exactly matches the
+.B rootdn
+of the database the ACLs apply to, because it implicitly
+possesses write privileges for the entire tree of that database.
+Actually, access control is bypassed for the
+.BR rootdn ,
+to solve the intrinsic chicken-and-egg problem.
 .LP
 The statement
 .B dnattr=<attrname>
@@ -269,20 +513,35 @@ The optional parameters
 and
 .B <attrname>
 define the objectClass and the member attributeType of the group entry.
+The defaults are
+.B groupOfNames
+and
+.BR member ,
+respectively.
 The optional style qualifier
 .B <style>
 can be
-.BR regex ,
+.BR expand ,
 which means that
 .B <group>
 will be expanded as a replacement string (but not as a regular expression)
-according to regex (7), and
-.B base
-or
-.B exact
-(an alias of
-.BR base ),
+according to
+.BR regex (7)
+and/or
+.BR re_format (7),
+and
+.BR exact ,
 which means that exact match will be used.
+If the style of the DN portion of the
+.B <what>
+clause is regex, the submatches are made available according to
+.BR regex (7)
+and/or
+.BR re_format (7);
+other styles provide limited submatches as discussed above about 
+the DN form of the 
+.B <by>
+clause.
 .LP
 For static groups, the specified attributeType must have
 .B DistinguishedName
@@ -293,7 +552,7 @@ be a subtype of the
 .B labeledURI
 attributeType. Only LDAP URIs of the form
 .B ldap:///<base>??<scope>?<filter>
-will be evaluated in a dynamic group.
+will be evaluated in a dynamic group, by searching the local server only.
 .LP
 The statements
 .BR peername=<peername> ,
@@ -301,7 +560,14 @@ The statements
 .BR domain=<domain> ,
 and
 .BR sockurl=<sockurl>
-mean that the contacting host IP for
+mean that the contacting host IP (in the form 
+.BR "IP=<ip>:<port>"
+for IPv4, or
+.BR "IP=[<ipv6>]:<port>"
+for IPv6)
+or the contacting host named pipe file name (in the form
+.B "PATH=<path>"
+if connecting through a named pipe) for
 .BR peername ,
 the named pipe file name for
 .BR sockname ,
@@ -316,9 +582,71 @@ The same
 .B style
 rules for pattern match described for the
 .B group
-case apply. 
+case apply, plus the
+.B regex
+style, which implies submatch
+.B expand
+and regex match of the corresponding connection parameters.
+The
+.B exact
+style of the
+.BR <peername>
+clause (the default) implies a case-exact match on the client's
+.BR IP , 
+including the
+.B "IP="
+prefix and the trailing
+.BR ":<port>" , 
+or the client's 
+.BR path ,
+including the
+.B "PATH="
+prefix if connecting through a named pipe.
+The special
+.B ip
+style interprets the pattern as 
+.BR <peername>=<ip>[%<mask>][{<n>}] ,
+where
+.B <ip>
+and 
+.B <mask>
+are dotted digit representations of the IP and the mask, while
+.BR <n> ,
+delimited by curly brackets, is an optional port.
+The same applies to IPv6 addresses when the special
+.B ipv6
+style is used.
+When checking access privileges, the IP portion of the
+.BR peername 
+is extracted, eliminating the
+.B "IP="
+prefix and the
+.B ":<port>"
+part, and it is compared against the
+.B <ip>
+portion of the pattern after masking with
+.BR <mask> :
+\fI((peername & <mask>) == <ip>)\fP.
+As an example, 
+.B peername.ip=127.0.0.1
+and
+.B peername.ipv6=::1
+allow connections only from localhost,
+.B peername.ip=192.168.1.0%255.255.255.0 
+allows connections from any IP in the 192.168.1 class C domain, and
+.B peername.ip=192.168.1.16%255.255.255.240{9009}
+allows connections from any IP in the 192.168.1.[16-31] range 
+of the same domain, only if port 9009 is used.
+The special 
+.B path
+style eliminates the 
+.B "PATH="
+prefix from the 
+.B peername
+when connecting through a named pipe, and performs an exact match 
+on the given pattern.
 The
-.BR domain 
+.BR <domain>
 clause also allows the
 .B subtree
 style, which succeeds when a fully qualified name exactly matches the
@@ -328,6 +656,16 @@ pattern, or its trailing part, after a
 exactly matches the 
 .BR domain
 pattern.
+The 
+.B expand
+style is allowed, implying an
+.B exact 
+match with submatch expansion; the use of 
+.B expand 
+as a style modifier is considered more appropriate.
+As an example,
+.B domain.subtree=example.com
+will match www.example.com, but will not match www.anotherexample.com.
 The
 .B domain
 of the contacting host is determined by performing a DNS reverse lookup.
@@ -337,7 +675,7 @@ statement is strongly discouraged.  By default, reverse lookups are disabled.
 The optional
 .B domainstyle
 qualifier of the
-.B domain
+.B <domain>
 clause allows a
 .B modifier
 option; the only value currently supported is
@@ -348,7 +686,7 @@ the
 is not 
 .BR regex ,
 much like the analogous usage in 
-.B dn
+.B <dn>
 clause.
 .LP
 The statement
@@ -356,10 +694,32 @@ The statement
 is undocumented yet.
 .LP
 The statement
-.B aci=<attrname>
+.B dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
+means that access checking is delegated to the admin-defined method
+indicated by
+.BR <name> ,
+which can be registered at run-time by means of the
+.B moduleload
+statement.
+The fields
+.BR <options> ,
+.B <dynstyle>
+and
+.B <pattern>
+are optional, and are directly passed to the registered parsing routine.
+Dynacl is experimental; it must be enabled at compile time.
+.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
@@ -368,18 +728,19 @@ The statements
 .BR tls_ssf=<n> ,
 and
 .BR sasl_ssf=<n>
-set the required Security Strength Factor (ssf) required to grant access.
+set the minimum required Security Strength Factor (ssf) needed
+to grant access.  The value should be positive integer.
 .SH THE <ACCESS> FIELD
-The field
-.B <access> ::= [self]{<level>|<priv>}
+The optional field
+.B <access> ::= [[real]self]{<level>|<priv>}
 determines the access level or the specific access privileges the
 .B who 
 field will have.
 Its component are defined as
 .LP
 .nf
-	<level> ::= none|auth|compare|search|read|write
-	<priv> ::= {=|+|-}{w|r|s|c|x}+
+	<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
+	<priv> ::= {=|+|\-}{0|d|x|c|s|r|{w|a|z}|m}+
 .fi
 .LP
 The modifier
@@ -387,11 +748,17 @@ The modifier
 allows special operations like having a certain access level or privilege
 only in case the operation involves the name of the user that's requesting
 the access.
-It implies the user that requests access is bound.
+It implies the user that requests access is authorized.
+The modifier
+.B realself
+refers to the authenticated DN as opposed to the authorized DN of the
+.B self
+modifier.
 An example is the
 .B selfwrite
 access to the member attribute of a group, which allows one to add/delete
-its own DN from the member list of a group, without affecting other members.
+its own DN from the member list of a group, while being not allowed
+to affect other members.
 .LP
 The 
 .B level 
@@ -399,20 +766,39 @@ access model relies on an incremental interpretation of the access
 privileges.
 The possible levels are
 .BR none ,
+.BR disclose ,
 .BR auth ,
 .BR compare ,
 .BR search ,
 .BR read ,
+.BR write ,
 and
-.BR write .
+.BR manage .
 Each access level implies all the preceding ones, thus 
-.B write
-access will imply all accesses.
-While
-.B none
-is trivial, 
+.B manage
+grants all access including administrative access.
+The 
+.BR write
+access is actually the combination of
+.BR add
+and
+.BR delete ,
+which respectively restrict the write privilege to add or delete
+the specified
+.BR <what> .
+
+.LP
+The
+.B none 
+access level disallows all access including disclosure on error.
+.LP
+The
+.B disclose
+access level allows disclosure of information on error.
+.LP
+The 
 .B auth
-access means that one is allowed access to an attribute to perform
+access level means that one is allowed access to an attribute to perform
 authentication/authorization operations (e.g.
 .BR bind )
 with no other access.
@@ -430,21 +816,38 @@ access privileges will be only those defined by the clause.
 The 
 .B +
 and
-.B -
+.B \-
 signs add/remove access privileges to the existing ones.
 The privileges are
+.B m
+for manage,
 .B w
 for write,
+.B a
+for add,
+.B z
+for delete,
 .B r
 for read,
 .B s 
 for search,
 .B c 
-for compare, and
+for compare,
 .B x
-for authentication.
-More than one privilege can be added in one statement.
+for authentication, and
+.B d
+for disclose.
+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).
+Note that
+.B +az
+is equivalent to
+.BR +w .
 .LP
+If no access is given, it defaults to 
+.BR +0 .
+.SH THE <CONTROL> FIELD
 The optional field
 .B <control>
 controls the flow of access rule application.
@@ -495,23 +898,58 @@ or the (even more silly) example
 .LP
 which grants everybody search and compare privileges, and adds read
 privileges to authenticated clients.
+.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 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
 operation requires
-.B write (=w)
+.B add (=a)
 privileges on the pseudo-attribute 
 .B entry
 of the entry being added, and 
-.B write (=w)
+.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
@@ -519,30 +957,46 @@ 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 write (=w)
+.B delete (=z)
 privileges on the pseudo-attribute
 .B entry 
 of the entry being deleted, and
-.B write (=w)
+.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 attibutes being modified.
+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
@@ -551,24 +1005,35 @@ operation requires
 privileges on the pseudo-attribute
 .B entry
 of the entry whose relative DN is being modified,
-.B write (=w)
+.B delete (=z)
 privileges on the pseudo-attribute
 .B children
-of the old and new entry's parents, and
-.B write (=w)
+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 Write (=w)
+.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, for each entry, requires
+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.
-Then, the resulting entries are tested for 
+The resulting entries are finally tested for 
 .B read (=r)
 privileges on the pseudo-attribute
 .B entry
@@ -589,14 +1054,59 @@ 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
-.BR <dnstyle> ,
-to avoid possible incorrect specifications of the access rules as well
-as for performance (avoid unrequired regex matching when an exact
+.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 adminisistrator might create a rule of the form:
+An administrator might create a rule of the form:
 .LP
 .nf
 	access to dn.regex="dc=example,dc=com"
@@ -612,7 +1122,7 @@ To match the desired subtree, the rule would be more precisely
 written:
 .LP
 .nf
-	access to dn.regex="^(.+,)?dc=example,dc=com$$"
+	access to dn.regex="^(.+,)?dc=example,dc=com$"
 		by ...
 .fi
 .LP
@@ -628,22 +1138,22 @@ When writing submatch rules, it may be convenient to avoid unnecessary
 .B <dnstyle>
 use; for instance, to allow access to the subtree of the user 
 that matches the
-.B what
+.B <what>
 clause, one could use
 .LP
 .nf
-	access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$$"
-		by dn.regex="^uid=$1,dc=example,dc=com$$" write
+	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 to
+.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=$1,dc=example,dc=com" write
+	access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
+		by dn.exact,expand="uid=$2,dc=example,dc=com" write
 		by ...
 .fi
 .LP
@@ -663,10 +1173,11 @@ ETCDIR/slapd.conf
 default slapd configuration file
 .SH SEE ALSO
 .BR slapd (8),
+.BR slapd\-* (5),
+.BR slapacl (8),
+.BR regex (7),
+.BR re_format (7)
 .LP
 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
 .SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project