Re: [PATCH net-next] [RFC] netns: enable cross-ve Unix sockets

[Daniel Lezcano <dlezcano@fr.ibm.com>]

Denis V. Lunev wrote:
> On Wed, 2008-10-01 at 14:31 +0200, Daniel Lezcano wrote:
>> Pavel Emelyanov wrote:
>>>> So there are 2 cases:
>>>>   * full isolation : restriction on VPS
>>>>   * partial isolation : no restriction but *perhaps* problem when migrating
>>>>
>>>> Looks like we need an option per namespace to reduce the isolation for 
>>>> af_unix sockets :)
>>>>   - on (default): current behaviour => full isolation
>>>>   - off : partial isolation
>>> You mean some sysctl, that enables/disables this check in unix_find_socket_byinode?
>> Yes.
> 
> I do not see much sense with sysctl as:
> - check (cross-connected sockets) is required as we can start namespace
>   with already opened socket

Check when checkpointing ? If you inherit a socket from your parent 
namespace, this socket belongs to your parent and you should not 
checkpoint it, no ?

In case you allow cross-connected sockets, this check is mandatory I agree.

> - this kind of sharing is not implicit but explicit as normal isolated
>   containers _must_ have separate filesystems. In this case this
>   sharing requires explicit host administrator action to link socket
>   between containers

What are "normal isolated containers" ? Are they OpenVZ containers ? 
These containers belong to the system containers family. What happens 
with application containers, if I want to share the filesystem without 
breaking the isolation of the afunix sockets ?

The current code provides full isolation and this is in mainline. I 
don't think it is reasonable to change that. What I propose is to keep 
the current behaviour.

When you create a network namespace, you can change the behaviour inside 
this namespace via /proc/sys/net/unix/isolated (for example).

This option allows:
1 - to connect to af_unix not belonging to the container
2 - to accept af_unix connection from outside the container (avoid a 
container to forbid the checkpoint of another container);