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

[Lennart Poettering]

On Thu, 05.03.15 12:16, Alban Crequy (alban.crequy at gmail.com) wrote:

> > Hmm, but what would you do for a service that has both PrivateNetwork
> > and chroot enabled?
> >
> > I am all open for shifting things around again, but I inda would
> > prefer a solution that works universally in the end...
> >
> > Ideas?
> >
> > 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...
> 
> I don't know what is the best solution but using a socket file seems
> better than using an abstract unix socket: processes in a
> systemd-nspawn container could discover the notify socket of the host
> in /proc/net/unix (if it does not use a new network namespace) and
> send garbage file descriptors with SCM_RIGHTS from the container to
> the host. Systemd on the host does the right thing: it closes the fds
> when the datagram was not sent by a managed unit. 

Well, this is only an issue if people do not use network
namespacing. But if they don't use it they should not expect that much
isolation. It's the deal they make...

> Does
> manager_get_unit_by_pid() matches the exact cgroup path only or does
> it also matches a prefix path? I wonder about nspawn containers
> started by a service unit on the host.

No, it cares for subtree membership only. THat said, access can be
restricted via NotifyAccess=. If people set it to NotifyAccess=all
they of course need to know what they are doing...

Lennart

-- 
Lennart Poettering, Red Hat