linux-kernel - Re: [PATCH 0/6] cgroup: add isolation_root flag, poor man's namespaces for cgroups

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Oct 2011 12:25:59 +0200
From:	Witold Krecicki <wpk@...m.net>
To:	Paul Menage <paul@...lmenage.org>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Matt Helsley <matthltc@...ibm.com>
Subject: Re: [PATCH 0/6] cgroup: add isolation_root flag, poor man's namespaces for cgroups

Dnia czwartek, 20 października 2011 o 12:11:54 Paul Menage napisał(a):
> After talking with Eric Biederman at LPC about the virtualizability of
> containers, I was wondering whether we could go even further, and say
> that a hierarchy (in the sense of a tree of cgroups with a bound set
> of subsystems) could be broken at the point of an isolation root. The
> container could then construct its own hierarchies with potentially
> different combinations of subsystems.
I tried to make it as simple as possible - and this approach (looking at patch 
length) seemed to be the simplest (we really don't care about 'other' cgroups 
that might appear). Other approaches would probably require major rewrites of 
cgroups code.

> > I'm really not sure if the 'mount' part (patch 5) is done correctly,
> > please review carefully.
> 
> It looks simple, I agree, and as though it *ought* to work. My first
> worry with this was that if the parent system unmount the hierarchy,
> and all the tasks in the child container died (so its namespace was
> cleaned up), what would keep the root or the parent-created hierarchy
> alive? But I think that since the super-block also has a reference on
> the root dentry itself, it should be OK.
I've tested it and 'it works' so no problem there :)
I'm currently testing this setup with several containers launched under 
modified LXC (creating 'container_name' cgroup, then 'container_name/rootfs', 
then setting them both to desired values and putting init in 
'container_name/rootfs') - no problems so far.

-- 
Witold Krecicki


--
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/