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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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