Name

slapd−sock — Socket backend to slapd

Synopsis

ETCDIR/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 external 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 addition 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 modified 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

ETCDIR/slapd.conf

default slapd configuration file

SEE ALSO

slapd.conf(5), slapd-config(5), slapd(8).

AUTHOR

Brian Candler


See the following documents: COPYRIGHTLICENSE