Quoting H. Peter Anvin (hpa@xxxxxxxxx): > Serge E. Hallyn wrote: >>> >>> 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. >> > > No, uid namespace is not the right thing for this. If anything, it For what? uid ns is right for file access controls among namespaces, and I'm just detailing what the uid ns file controls will buy you in terms of the procsys limits file... I actually do prefer having the file write handler check for CAP_SYS_RESOURCE, but have conceded that battle at least in the cgroup arena. > should be controlled by a capability flag. This is a general issue for > procfs and sysfs as used for controlling any kind of system resources, > though. > >> 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. > > What probably would make more sense is to limit containers to a specific > number of inodes or open file descriptors. The pty limit was a quick > hack to avoid DoS, but it's really equivalent (with a small multiplier, > ~3 or so) to "open inodes". Yes that (# inodes) sounds good. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
