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

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

Pavel Emelyanov wrote:
> Daniel Lezcano wrote:
>> Pavel Emelyanov wrote:
>>>> Yes per namespace, I agree.
>>>>
>>>> If the option is controlled by the parent and it is done by sysctl, you 
>>>> will have to make proc/sys per namespace like Pavel did with /proc/net, no ?
>>> /proc/sys is already per namespace actually ;) Or what did you mean by that?
>>
>> Effectively I was not clear :)
>>
>> I meant, you can not access /proc/sys from outside the namespace like 
>> /proc/net which can be followed up by /proc/<pid>/net outside the namespace.
> 
> Ah! I've got it. Well, I think after Al Viro finishes with sysctl
> rework this possibility will appear, but Denis actually persuaded me
> in his POV - if we do want to disable shared sockets we *can* do this
> by putting containers in proper mount namespaces of chroot environments.

And I agree with this point. But :)

  1 - the current behaviour is full isolation. Shall we/can we change 
that without taking into account there are perhaps some people using 
this today ? I don't know.

  2 - I wish to launch a non chrooted application inside a namespace, 
sharing the file system without sharing the af_unix sockets, because I 
don't want the application running inside the container overlap with the 
socket af_unix of another container. I prefer to detect a collision with 
a strong isolation and handle it manually (remount some part of the fs 
for example).

  3 - I would like to be able to reduce this isolation (your point) to 
share the af_unix socket for example to use /dev/klog or something else.

I don't know how much we can consider the point 1, 2 pertinent, but 
disabling 3 lines of code via a sysctl with strong isolation as default 
and having a process unsharing the namespace in userspace and changing 
this value to less isolation is not a big challenge IMHO :)