On Fri, Aug 28, 2020 at 12:29 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > > Just to scope how much work it would be to fix rlimits > so they are not a problem for user namespaces I took a quick > survey. > > The rlimits can be found in > include/uapi/asm-generic/resource.h > > There are a total of 16 rlimits. > There are only 4 rlimits that are enforced at anything other > than process granularity. > > RLIMIT_NPROC > RLIMIT_MEMLOCK > RLIMIT_SIGPENDING > RLIMIT_MSGQUEUE > > So it should not be difficult to fix those rlimits. What are your proposed semantics for what the "fix" would look like? Or are you saying that once we take on Christian's proposal of 64-bit kuid they would be trivial to fix? I think the reason we didn't move forward with fixing it is the only real thing we could agree upon is an rlimit namespace, and then you get into a question of why do these even exist, and should they just be cgroup(v2) controllers, and should calling setrlimit just be a wrapper around a cgroup(v2) controller that has a map of uid -> limit? > > I think the implementation of RLIMIT_MEMLOCK is highly suspect, and > might be worth reexamining, as RLMIT_MEMLOCK it interpreted differently > in different contexts. For the limit there is mm->locked_vm, > user->lock_vm, and user->locked_shm. > > Eric > > > > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
