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: Tue, 3 Mar 2015 22:00:24 +0000 (UTC) From: Luke Leighton <lkcl@...l.net> To: linux-kernel@...r.kernel.org Subject: Re: cgroup: status-quo and userland efforts Serge Hallyn <serge.hallyn@...> writes: > > Quoting Tim Hockin (thockin@...): > > > FWIW, the code is too embarassing yet to see daylight, but I'm playing > > > with a very lowlevel cgroup manager which supports nesting itself. > > > Access in this POC is low-level ("set freezer.state to THAWED for cgroup > > > /c1/c2", "Create /c3"), but the key feature is that it can run in two > > > modes - native mode in which it uses cgroupfs, and child mode where it > > > talks to a parent manager to make the changes. > > > > In this world, are users able to read cgroup files, or do they have to > > go through a central agent, too? > > The agent won't itself do anything to stop access through cgroupfs, but > the idea would be that cgroupfs would only be mounted in the agent's > mntns. My hope would be that the libcgroup commands (like cgexec, > cgcreate, etc) would know to talk to the agent when possible, and users > would use those. serge, i realise this is a year on, so you probably have something at least working by now... but i have a possibly crazy idea.. would it be possible or convenient for the agent that you are writing to emulate - in userspace - the *exact* same interface as /dev/cgroups, providing a controlled hierarchy yet presenting itself to other processes in such a way that its hierarchical management would be completely transparent to anything that used it? including of course a new instance of the agent itself, in a recursive fashion :) the important question on top of this would be: is there anything that needs to be atomic which emulation of the /dev/cgroups kernel API in userspace could not handle? l. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists