конфигурация доступа для slapd, автономного демона LDAP (access configuration for slapd, the stand-alone LDAP daemon)
THE <WHO> FIELD
The field <who> indicates whom the access rules apply to.
Multiple <who> statements can appear in an access control
statement, indicating the different access privileges to the same
resource that apply to different accessee. It can have the forms
*
anonymous
users
self[.<selfstyle>]
dn[.<dnstyle>[,<modifier>]]=<DN>
dnattr=<attrname>
realanonymous
realusers
realself[.<selfstyle>]
realdn[.<dnstyle>[,<modifier>]]=<DN>
realdnattr=<attrname>
group[/<objectclass>[/<attrname>]]
[.<groupstyle>]=<group>
peername[.<peernamestyle>]=<peername>
sockname[.<style>]=<sockname>
domain[.<domainstyle>[,<modifier>]]=<domain>
sockurl[.<style>]=<sockurl>
set[.<setstyle>]=<pattern>
ssf=<n>
transport_ssf=<n>
tls_ssf=<n>
sasl_ssf=<n>
dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
with
<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>]
They may be specified in combination.
The wildcard * refers to everybody.
The keywords prefixed by real act as their counterparts without
prefix; the checking respectively occurs with the authentication
DN and the authorization DN.
The keyword anonymous means access is granted to unauthenticated
clients; it is mostly used to limit access to authentication
resources (e.g. the userPassword attribute) to unauthenticated
clients for authentication purposes.
The keyword users means access is granted to authenticated
clients.
The keyword 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 level{<n>} style, where <n>
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 "by self.level{1} ..." clause would match when the object
"dc=example,dc=com" is accessed by "cn=User,dc=example,dc=com".
A "by self.level{-1} ..." clause would match when the same user
accesses the object "ou=Address Book,cn=User,dc=example,dc=com".
The statement dn=<DN> means that access is granted to the
matching DN. The optional style qualifier dnstyle allows the
same choices of the dn form of the <what> field. In addition,
the regex style can exploit substring substitution of submatches
in the <what> dn.regex clause by using the form $<digit>, with
digit ranging from 0 to 9 (where 0 matches the entire string), or
the form ${<digit>+}, for submatches higher than 9. Substring
substitution from attribute value can be done in using the form
${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.
access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
The style qualifier allows an optional modifier. At present, the
only type allowed is expand, which causes substring substitution
of submatches to take place even if dnstyle is not regex. Note
that the regex dnstyle in the above example may be of use only if
the <by> clause needs to be a regex; otherwise, if the value of
the second (from the right) dc= portion of the DN in the above
example were fixed, the form
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$2,dc=example,dc=com" write
could be used; if it had to match the value in the <what> clause,
the form
access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
by dn.exact,expand="uid=$2,dc=$3,dc=com" write
could be used.
Forms of the <what> clause other than regex may provide
submatches as well. The base(object), the sub(tree), the
one(level), and the children forms provide $0 as the match of the
entire string. The sub(tree), the one(level), and the children
forms also provide $1 as the match of the rightmost part of the
DN as defined in the <what> clause. This may be useful, for
instance, to provide access to all the ancestors of a user by
defining
access to dn.subtree="dc=com"
by dn.subtree,expand="$1" read
which means that only access to entries that appear in the DN of
the <by> clause is allowed.
The level{<n>} form is an extension and a generalization of the
onelevel form, which matches all DNs whose <n>-th ancestor is the
pattern. So, level{1} is equivalent to onelevel, and level{0} is
equivalent to base.
It is perfectly useless to give any access privileges to a DN
that exactly matches the 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 rootdn, to solve the intrinsic chicken-and-egg
problem.
The statement dnattr=<attrname> means that access is granted to
requests whose DN is listed in the entry being accessed under the
<attrname> attribute.
The statement group=<group> means that access is granted to
requests whose DN is listed in the group entry whose DN is given
by <group>. The optional parameters <objectclass> and <attrname>
define the objectClass and the member attributeType of the group
entry. The defaults are groupOfNames and member, respectively.
The optional style qualifier <style> can be expand, which means
that <group> will be expanded as a replacement string (but not as
a regular expression) according to regex(7) and/or re_format(7),
and exact, which means that exact match will be used. If the
style of the DN portion of the <what> clause is regex, the
submatches are made available according to regex(7) and/or
re_format(7); other styles provide limited submatches as
discussed above about the DN form of the <by> clause.
For static groups, the specified attributeType must have
DistinguishedName or NameAndOptionalUID syntax. For dynamic
groups the attributeType must be a subtype of the labeledURI
attributeType. Only LDAP URIs of the form
ldap:///<base>??<scope>?<filter> will be evaluated in a dynamic
group, by searching the local server only.
The statements peername=<peername>, sockname=<sockname>,
domain=<domain>, and sockurl=<sockurl> mean that the contacting
host IP (in the form IP=<ip>:<port> for IPv4, or
IP=[<ipv6>]:<port> for IPv6) or the contacting host named pipe
file name (in the form PATH=<path> if connecting through a named
pipe) for peername, the named pipe file name for sockname, the
contacting host name for domain, and the contacting URL for
sockurl are compared against pattern to determine access. The
same style rules for pattern match described for the group case
apply, plus the regex style, which implies submatch expand and
regex match of the corresponding connection parameters. The
exact style of the <peername> clause (the default) implies a
case-exact match on the client's IP, including the IP= prefix and
the trailing :<port>, or the client's path, including the PATH=
prefix if connecting through a named pipe. The special ip style
interprets the pattern as <peername>=<ip>[%<mask>][{<n>}], where
<ip> and <mask> are dotted digit representations of the IP and
the mask, while <n>, delimited by curly brackets, is an optional
port. The same applies to IPv6 addresses when the special ipv6
style is used. When checking access privileges, the IP portion
of the peername is extracted, eliminating the IP= prefix and the
:<port> part, and it is compared against the <ip> portion of the
pattern after masking with <mask>: ((peername & <mask>) == <ip>).
As an example, peername.ip=127.0.0.1 and peername.ipv6=::1 allow
connections only from localhost,
peername.ip=192.168.1.0%255.255.255.0 allows connections from any
IP in the 192.168.1 class C domain, and
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 path style eliminates the
PATH= prefix from the peername when connecting through a named
pipe, and performs an exact match on the given pattern. The
<domain> clause also allows the subtree style, which succeeds
when a fully qualified name exactly matches the domain pattern,
or its trailing part, after a dot, exactly matches the domain
pattern. The expand style is allowed, implying an exact match
with submatch expansion; the use of expand as a style modifier is
considered more appropriate. As an example,
domain.subtree=example.com will match www.example.com, but will
not match www.anotherexample.com. The domain of the contacting
host is determined by performing a DNS reverse lookup. As this
lookup can easily be spoofed, use of the domain statement is
strongly discouraged. By default, reverse lookups are disabled.
The optional domainstyle qualifier of the <domain> clause allows
a modifier option; the only value currently supported is expand,
which causes substring substitution of submatches to take place
even if the domainstyle is not regex, much like the analogous
usage in <dn> clause.
The statement set=<pattern> is undocumented yet.
The statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
means that access checking is delegated to the admin-defined
method indicated by <name>, which can be registered at run-time
by means of the moduleload statement. The fields <options>,
<dynstyle> and <pattern> are optional, and are directly passed to
the registered parsing routine. Dynacl is experimental; it must
be enabled at compile time.
The statement dynacl/aci[=<attrname>] means that the access
control is determined by the values in the attrname of the entry
itself. The optional <attrname> indicates what attributeType
holds the ACI information in the entry. By default, the
OpenLDAPaci operational attribute is used. ACIs are
experimental; they must be enabled at compile time.
The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and
sasl_ssf=<n> set the minimum required Security Strength Factor
(ssf) needed to grant access. The value should be positive
integer.
