SLAPD-SOCK(5)SLAPD-SOCK(5)NAMEslapd-sock - Socket backend to slapd
SYNOPSIS
/etc/openldap/slapd.conf
DESCRIPTION
The Socket backend to slapd(8) uses an external program to handle
queries, similarly to slapd-shell(5). However, in this case the exter‐
nal program listens on a Unix domain socket. This makes it possible to
have a pool of processes, which persist between requests. This allows
multithreaded operation and a higher level of efficiency. The external
program must have been started independently; slapd(8) itself will not
start it.
CONFIGURATION
These slapd.conf options apply to the SOCK backend database. That is,
they must follow a "database sock" line and come before any subsequent
"backend" or "database" lines. Other database options are described in
the slapd.conf(5) manual page.
extensions [ binddn | peername | ssf ]*
Enables the sending of additional meta-attributes with each
request.
binddn: <bound DN>
peername: IP=<address>:<port>
ssf: <SSF value>
socketpath <pathname>
Gives the path to a Unix domain socket to which the commands
will be sent and from which replies are received.
PROTOCOL
The protocol is essentially the same as slapd-shell(5) with the addi‐
tion of a newline to terminate the command parameters. The following
commands are sent:
ADD
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
<entry in LDIF format>
<blank line>
BIND
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
dn: <DN>
method: <method number>
credlen: <length of <credentials>>
cred: <credentials>
<blank line>
COMPARE
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
dn: <DN>
<attribute>: <value>
<blank line>
DELETE
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
dn: <DN>
<blank line>
MODIFY
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
dn: <DN>
<repeat {
<"add"/"delete"/"replace">: <attribute>
<repeat { <attribute>: <value> }>
-
}>
<blank line>
MODRDN
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
dn: <DN>
newrdn: <new RDN>
deleteoldrdn: <0 or 1>
<if new superior is specified: "newSuperior: <DN>">
<blank line>
SEARCH
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
base: <base DN>
scope: <0-2, see ldap.h>
deref: <0-3, see ldap.h>
sizelimit: <size limit>
timelimit: <time limit>
filter: <filter>
attrsonly: <0 or 1>
attrs: <"all" or space-separated attribute list>
<blank line>
UNBIND
msgid: <message id>
<repeat { "suffix:" <database suffix DN> }>
<blank line>
The commands - except unbind - should output:
RESULT
code: <integer>
matched: <matched DN>
info: <text>
where only RESULT is mandatory, and then close the socket. The search
RESULT should be preceded by the entries in LDIF format, each entry
followed by a blank line. Lines starting with `#' or `DEBUG:' are
ignored.
ACCESS CONTROL
The sock backend does not honor all ACL semantics as described in
slapd.access(5). In general, access to objects is checked by using a
dummy object that contains only the DN, so access rules that rely on
the contents of the object are not honored. In detail:
The add operation does not require write (=w) access to the children
pseudo-attribute of the parent entry.
The bind operation requires auth (=x) access to the entry pseudo-
attribute of the entry whose identity is being assessed; auth (=x)
access to the credentials is not checked, but rather delegated to the
underlying program.
The compare operation requires compare (=c) access to the entry pseudo-
attribute of the object whose value is being asserted; compare (=c)
access to the attribute whose value is being asserted is not checked.
The delete operation does not require write (=w) access to the children
pseudo-attribute of the parent entry.
The modify operation requires write (=w) access to the entry pseudo-
attribute; write (=w) access to the specific attributes that are modi‐
fied is not checked.
The modrdn operation does not require write (=w) access to the children
pseudo-attribute of the parent entry, nor to that of the new parent, if
different; write (=w) access to the distinguished values of the naming
attributes is not checked.
The search operation does not require search (=s) access to the entry
pseudo_attribute of the searchBase; search (=s) access to the
attributes and values used in the filter is not checked.
EXAMPLE
There is an example script in the slapd/back-sock/ directory in the
OpenLDAP source tree.
FILES
/etc/openldap/slapd.conf
default slapd configuration file
SEE ALSOslapd.conf(5), slapd-config(5), slapd(8).
AUTHOR
Brian Candler
OpenLDAP 2.4.23 2010/06/30 SLAPD-SOCK(5)
