lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 21 May 2016 02:29:55 +1000 From: Aleksa Sarai <asarai@...e.de> To: James Bottomley <James.Bottomley@...senPartnership.com>, Tejun Heo <tj@...nel.org> Cc: Li Zefan <lizefan@...wei.com>, Johannes Weiner <hannes@...xchg.org>, Aleksa Sarai <cyphar@...har.com>, cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, dev@...ncontainers.org Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces >> This is stemming from the fact that an unpriv application can't >> create its sub-cgroups without explicit delegation from the root and >> that has always been an explicit design choice. >> It's tied to who's responsible for cleanup afterwards and what >> happens when the process gets migrated to a different cgroup. The >> latter is an important issue on v1 hierarchies because migrating >> tasks sometimes is used as a way to control resource distribution. > > OK, so is the only problem cleanup? If so, what if I proposed that a > cgroup directory could only be created by the owner of the userns > (which would be any old unprivileged user) iff they create a cgroup ns > and the cgroup ns would be responsible for removing it again, so the > cgroup subdirectory would be tied to the cgroup namespace as its holder > and we'd use release of the cgroup to remove all the directories? The only question I'd have is how would we deal with visibility (and should a "parent" cgroup namespace be able to modify things inside the cgroup?). And of course, how would that interact with VFS? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
Powered by blists - more mailing lists