Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> Daniel Lezcano <daniel.lezcano@xxxxxxx> writes: >> >> >>> 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 ? >>> >> I hardly how that is significant. Anyone can allocate the rest of the possible >> pty's today. The situation does not get worse with devpts. >> >> If you want security and permission arguments get with Serge and finish >> the uid namespace. The you will have a user that looks like root but >> does not have permissions to do most things. >> > > Right, and in particular the way it would partially solve this issue is > that the procsys limit file would be owned by root in the initial uid > namespace, so root in a child container would not be able to write to > it. > > Defining a new mount option to set a per-sb limit seems useful though, > as I could easily see wanting to limit containers (on a 1000-container > system) to 3 ptys each for instance. > Yep, I changed my mind, I think Eric and HPA are right. devpts is a file system and not a namespace even if the result is the same. That makes sense to keep a global sysctl for the root container and handle security problem with user namespace and mount option. >>> 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? >>> >> No. Either we add a pty_max value to the filesystem like we did with ptmx >> or we forget it. >> > > -serge > > > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
