SLAPD-SOCK(5)

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