]> git.sur5r.net Git - openldap/blobdiff - doc/man/man5/slapd.access.5
A few clarifications. "sync" in syncprov should refer to the
[openldap] / doc / man / man5 / slapd.access.5
index 15df671a0ee62f6d2d542cb16b5a15edb60ac6ee..bf3f7f22ebd75c66ad83c2ba8504dcb4dc6884c2 100644 (file)
@@ -1,5 +1,5 @@
 .TH SLAPD.ACCESS 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 1998-2005 The OpenLDAP Foundation All Rights Reserved.
+.\" Copyright 1998-2006 The OpenLDAP Foundation All Rights Reserved.
 .\" Copying restrictions apply.  See COPYRIGHT/LICENSE.
 .SH NAME
 slapd.access \- access configuration for slapd, the stand-alone LDAP daemon
@@ -66,13 +66,57 @@ 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>
@@ -80,9 +124,9 @@ specifies the entity the access control directive applies to.
 It can have the forms
 .LP
 .nf
-       [dn[.<dnstyle>]=]<dnpattern>
+       dn[.<dnstyle>]=<dnpattern>
        filter=<ldapfilter>
-       attrs=<attrlist>[ val[.<attrstyle>]=<attrval>]
+       attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
 .fi
 .LP
 with
@@ -98,9 +142,6 @@ with
 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.
@@ -112,11 +153,7 @@ form is given.
 .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 ),
@@ -157,7 +194,7 @@ 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
@@ -190,13 +227,13 @@ form is given,
 is implied, i.e. all attributes are addressed.
 .LP
 Using the form
-.B attrs=<attr> val[.<attrstyle>]=<attrval>
+.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. The
 .B <attrstyle>
 .B exact
 (the default) uses the attribute's equality matching rule to compare the
-value. If the
+value, unless a different (and compatible) matching rule is specified. If the
 .B <attrstyle>
 is
 .BR regex ,
@@ -254,8 +291,7 @@ It can have the forms
        tls_ssf=<n>
        sasl_ssf=<n>
 
-       aci[=<attrname>]
-       dynacl/name[.<dynstyle>][=<pattern>]
+       dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
 .fi
 .LP
 with
@@ -270,6 +306,7 @@ with
        <domainstyle>={exact|regex|sub(tree)}
        <setstyle>={exact|regex}
        <modifier>={expand}
+       <name>=aci              <pattern>=<attrname>]
 .fi
 .LP
 They may be specified in combination.
@@ -620,20 +657,7 @@ The statement
 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>[.<dynstyle>][=<pattern>]
+.B dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
 means that access checking is delegated to the admin-defined method
 indicated by
 .BR <name> ,
@@ -641,17 +665,25 @@ 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.
-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> ,
@@ -662,7 +694,7 @@ and
 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 
@@ -670,8 +702,8 @@ field will have.
 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
@@ -704,8 +736,8 @@ The possible levels are
 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 
@@ -738,6 +770,8 @@ and
 .B -
 signs add/remove access privileges to the existing ones.
 The privileges are
+.B m
+for manage,
 .B w
 for write,
 .B r
@@ -753,6 +787,7 @@ 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).
+.LP
 If no access is given, it defaults to 
 .BR +0 .
 .SH THE <CONTROL> FIELD
@@ -806,11 +841,32 @@ 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
@@ -823,6 +879,10 @@ of the entry being added, and
 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
@@ -830,12 +890,14 @@ 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
@@ -848,12 +910,14 @@ of the entry being deleted, and
 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
@@ -873,6 +937,7 @@ 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
@@ -905,6 +970,7 @@ access to the attribute holding the referral information
 (generally the
 .B ref
 attribute).
+
 .LP
 Some internal operations and some
 .B controls
@@ -932,9 +998,8 @@ 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),
-.BR back-hdb (5),
 and
-.BR back-ldbm (5).
+.BR back-hdb (5).
 
 Some other backend, like
 .BR back-sql (5),