pipe-tools
Software
www.skarnet.org
The nptlistend program
nptlistend is an executable wrapper around the
nptrigger_block call.
- It reads a request on stdin, as it is sent
by nptrigger_sendinfo().
- It then listens on the relevant fifodir, waiting for the relevant events,
writing a null byte on stdout when it has begun to listen.
- It exits 111 on error, 99 on timeout, 0 if stdin closes.
- If it gets the notification it was asked for, it writes the
answer to stdout and exits 0.
nptlistend is normally spawned by the nptrigger_listenf()
library call and runs as child process of the caller. But it may sometimes
be inconvenient; you can then use a nptlistend service instead.
Setting up a nptlistend service
Simply run nptlistend under a Unix super-server like
ipcserver
or unixserver.
Consult your Unix super-server documentation to know how to set up
such a service. If you are a
daemontools user
- which you should be -, you can use the example service directory
provided in the service/nptlistend subdirectory of the
pipe-tools package.
The socket your super-server listens on must match the name defined
as NPT_IPCPATH, defined in include/nptrigger.h.
If you wish to change it, you will have to edit
src/libnptrigger/nptrigger.h and recompile the pipe-tools
package.
Thoughts on security of the nptlistend service
The point of a daemon is to run as a unique user. It's useful when
you want to provide a service with the same rights for everyone:
for instance, you run a SMTP server as the qmaild or the
postfix user, and it's part of the security model. But it's
not the case here: nptlistend is a client
program, that should run with the caller's privileges. Two
separate instances of nptlistend, run by two different users,
should not share the same privileges.
The nptlistend service approach goes against that! If you run
your Unix super-server as the nptrigger user, then all
nptlistend processes spawned by nptrigger_listen()
calls will run will the privileges of that user, not with the
caller's privileges. What can we do?
- Don't care. Set up a filesystem hierarchy belonging to the
nptrigger user and the nptrigger group, allowing
everyone in the nptrigger group to notify any listener
on any path. Not very satisfactory.
- Run the super-server as root, and give every nptlistend
instance the privileges of the caller. This is possible if you
can pass credentials through a Unix domain socket, i.e. if your
system supports the
getpeereid
call. The problem is that it is not portable.
The only portable solution is to avoid using the service when possible:
run nptlistend as a child process of the caller when you can,
using the
nptrigger_listenf()
library call instead of nptrigger_listen().