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 :) _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers