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. > > 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