On Sat, 07.03.15 00:20, Alban Crequy (alban.cre...@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 -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
