The s6-fdholderd program

s6-fdholderd is the serving part of the s6-fdholder-daemon fd-holding server. It assumes that its stdin is a bound and listening Unix domain socket; it accepts connections from clients connecting to that socket, and stores and retrieves file descriptors on their behalf.


     s6-fdholderd [ -1 ] [ -v verbosity ] [ -c maxconn ] [ -n maxfds ] [ -t clienttimeout ] [ -T lameducktimeout ] [ -i rulesdir | -x rulesfile ]





Before running s6-fdholderd (or its wrapper s6-fdholder-daemon), it is necessary to configure it. This is done by a series of rules, or ruleset, stored in either a rulesfile in the CDB format, or in a rulesdir, i.e. a directory in the filesystem following a certain format. s6-fdholderd will refuse to run if neither the -i nor the -x option has been provided.

Rulesets can be converted between the rulesdir and rulesfile formats with the s6-accessrules-cdb-from-fs and s6-accessrules-fs-from-cdb conversion tools.

Rules format

The rules file, or rules directory, follows the s6 accessrules format for uid and gid checking. For every connecting client, s6-fdholderd matches the uid and gid of the client against the provided ruleset, and determines what the client is authorized to do.

By default, no client is allowed to do anything - not even connect to the server. Even root, the super-user, will be denied access. That is why it is essential to create a sensible ruleset prior to running the server in order to do anything useful.

The various rights that a client can have are the following (using a rulesdir as an example, but a rulesfile works the same way):

The other rights are defined in the "environment" part of the ruleset:

Configuration examples

Assuming you want to run a s6-fdholderd daemon in the /service/fdholder directory with the -i rules option, you should:

Depending on your policy, you should now give certain rights to certain users or groups. For instance: