H. Peter Anvin wrote: > Daniel Lezcano wrote: >>> >>> Resource limit partitioning is a much bigger and orthogonal problem. >>> >> In this case we don't have the pty allocated independently, no ? >> I mean one container can allocate 4095 pty, making a pty starvation >> for others containers. Or imagine I am a vilain and I want to mess >> the other containers, I can do echo 0 > /proc/sys/kernel/pty/max. >> AFAIR, we said people making isolation of a resource is in charge (if >> it is relevant), to take into account the /proc/sys part. >> >> For example, making the network per namespace all the network >> configuration variable located in /proc/sys/net are per namespace >> too. When it is irrelevant the file is read-only or just not displayed. >> >> IMHO, pty/max and pty/nr is part of the "multiple devpts instances" >> feature. >> > > Naming and resource partitioning are two orthogonal issues, regardless > of what's IYHO. > > Really. You have the same classes of issues with ANY allocatable > resource in the system. Period. Furthermore, there are quite a few > applications which want one and not the other. Trying to entangle > them is broken. Mmh, perhaps there is a misunderstanding here. The devpts new instance has been principally implemented for the container isolation. The container chroots to a private rootfs, does a new instance of devpts, mount it to /dev/pts and should remount /proc too. The first implementation of the devpts was a namespace approach but finally it looks like it was not necessary to use a new clone flag because the mount namespace with the ability to do multiple instances of devpts was enough. Each time we implemented a new namespace, we tried to take into account the /proc/sys part. For example, you can modify /proc/sys/kernel/msgmax without impacting the other namespaces, you can modify /proc/sys/net/unix/max_dgram_qlen without having this configuration being propagated to other namespaces. One other good example is the /proc/sys/net/ipv4/route/flush where the routes are flushed only for the current namespace. Why we did this ? because someone in another container can flush the routes of the other containers. I agree we can found thousand of example of different resources which are not partitioned and if you refer to multiple instances of devpts in the same context, it is probably pointless to take into account the sysctl. But if I am able to create a new instance of devpts for a container and modify the configuration of another devpts from this container, is it acceptable ? Can we convince people to use the containers for security and have anybody able to make a pty starvation from one container to another ? If it is too much complicated to handle one value per new devpts instance, IMHO /proc/sys/kernel/pty/max should be, at least, read-only for the new instance, no ? Thanks -- Daniel _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers