>monopolizing a system resource (e.g. IOPS or network bandwidth) People have been placing ulimits on users to limit their resource usage for decades, using cgr

>monopolizing a system resource (e.g. IOPS or network bandwidth) People have been placing ulimits on users to limit their resource usage for decades, using cgroups to do it is not a novel concept, just more effective. >rogue problems like termination of a hostile/stupid set of processes (cgroups and namespaces are one of the few reliable ways to kill process groups in non-racey ways, etc). The ability for a user to leave processes around on the system has been fixed for years now, with systemd-logind which puts each user in its own cgroup. >adding code to the kernel (module autoloading) This is a concern both for container systems and regular user isolation, and the only reliable way to fix it for either is to disable module autoloading, or at least restrict the available modules to well-maintained ones. >The original use cases for namespacing, cgroups, etc was precisely to give more fine-grained resource and isolation control over existing applications, in a hierarchical manner. Yes, and they failed. The design of Linux namespaces and cgroups is awful. You can perceive this by the fact that they require privileges to use. Hopefully in a few years all this Flatpak/Docker churn will output some namespacing APIs for Linux that are actually good.