Gao feng <gaofeng@xxxxxxxxxxxxxx> writes: > cc libvirt-list > > On 08/21/2013 01:30 PM, Eric W. Biederman wrote: >> Gao feng <gaofeng@xxxxxxxxxxxxxx> writes: >> >>> Unix sockets are private resources of net namespace, >>> allowing one net namespace to access to other netns's unix >>> sockets is meaningless. >> >> Allowing one net namespace to access another netns's unix socket is >> deliberate behavior. This is a desired and useful feature, and >> only a misconfiguration of visible files would allow this to be a >> problem. >> >>> I'm researching a problem about shutdown from container, >>> if the cotainer shares the same file /run/systemd/private >>> with host, when we run shutdown -h xxx in container, the >>> shutdown message will be send to the systemd-shutdownd >>> through unix socket /run/systemd/private, and because >>> systemd-shutdownd is running in host, so finally, the host >>> will become shutdown. >> >> The simple answer is don't do that then. I can see no reason >> to share /run outside of the container unless you want this kind of >> behavior. >> >> Quite frankly I want this behavior if I am using network namespaces >> to support multiple routing contexts. That is if I am using scripts >> like: >> >> ip netns add other >> ip netns exec other script >> >> I don't want to have to remember to say >> ip netns orig exec shutdown -h now >> >> There are more compelling uses and there is no cost in supporting this >> in the kernel. >> >> What kind of misconfiguration caused someone to complain about this? >> > > libvirt lxc allows user to set up a container which shares the same root > directory with host. > > seems like the unix sockets whose sun_path is an abstract socket address > are net namespace aware. > > Should we use "abstract" type of address instead of a file system pathname > for systemd in this case? I suspect libvirt should simply not share /run or any other normally writable directory with the host. Sharing /run /var/run or even /tmp seems extremely dubious if you want some kind of containment, and without strange things spilling through. Eric -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list