On Wed, 2008-10-01 at 18:15 +0200, Daniel Lezcano wrote: > 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. We have a direct request from people using to remove this state of isolation. > 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). with common filesystem you have to detect collisions at least for FIFOs. This situation is the same. Basically, if we'll treat named Unix sockets as an improved FIFO - it's better to use the same approach > 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 :) the real questions is _who_ is responsible for this kind of staff -> node (parent container) administrator or container administrator. I strongly vote for first. Also if we are talking about such kind of staff, I dislike global kludge. This should be a property of two concrete VEs and better two concrete sockets. Unfortunately, setsockopt is not an option :( _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers