[systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

Lennart Poettering lennart at poettering.net
Sun Mar 8 15:45:12 PDT 2015

On Sat, 07.03.15 00:20, Alban Crequy (alban.crequy at gmail.com) wrote:

> > I figure we could open a new mount namespace and mount the file system
> > socket into the chroot, but not sure I like the idea...
> Maybe that's the way to do it... but where would you bind mount the
> socket file? in $CHROOT/tmp which should be writeable when
> PrivateTmp=true? Of course it will not work if the daemon is doing the
> chroot itself instead of relying on systemd's RootDirectory.

/tmp is not a place for sockets.

Whatever code sets up the execution environment which wants to allow
notifications would have the responsibility to bind mount the
notification socket... I mean, the notification socket isn't really
too different from other sockets. If you run your php program in a
chroot, and you want ot to access your mysql server via AF_UNIX, then
you need to mount the socket over too, that's really the same story here...

> The same problem exists even without using
> PrivateNetwork/RootDirectory when the service starts a container with
> "nspawn --private-network" and the program inside the container wants
> to notify when it's ready. This has the same root cause: the service
> runs in a new mount/chroot and a new network namespace.

This is not a "problem". This is a feature. I mean, you asked for
isolation, hence you got isolation...

I am pretty sure that there should not be any way for container member
processes to communication via assumed-to-be-local IPC to processes
outside of the container, unless they do so with the container
manager. In this case meaning: if you want notification like this,
then your container manager needs to proxy that.

> There is also the additional problem that the program inside the
> container runs in a different cgroup (/system.slice/docker-... for
> docker containers, or /machine.slice... for nspawn containers).
> There is the tool "sdnotify-proxy" to proxy the notify socket from
> systemd to a socket file which can be bind mounted in the container.
> sdnotify-proxy works, but I would like to know if someone finds a
> better way for containers :)

I am not sure I understand what "sdnotify-proxy" does and who needs it?


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list