Re: [PATCH] netns: unix: only allow to find out unix socket in same net namespace

cc libvirt-list

On 08/21/2013 01:30 PM, Eric W. Biederman wrote:

Gao feng [off-list ref] writes:

quoted

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.

quoted

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?