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>] [day] [month] [year] [list]
Date:	Thu, 13 Oct 2011 09:05:01 +0200
From:	Witold Krecicki <wpk@...m.net>
To:	Matthew Helsley <matt.helsley@...il.com>
Cc:	Paul Menage <paul@...lmenage.org>, Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: [PATCH 0/6] cgroup: add isolation_root flag, poor man's namespaces for cgroups

Dnia czwartek, 13 października 2011 o 07:30:27 Matthew Helsley napisał(a):
> Unless I'm misunderstanding the problem this idea does not look great. It
> looks vaguely like mount namespaces, subtree mounts, and chroot all sort of
> rolled into one and presented in a very strange interface specific to
> cgroups.
>
> We already have the ability to mount a subtree of the filesystem as if it
> were the root of that filesystem. This seems somewhat similar except we
> lack the permission to mount or see anything above that particular subtree
> (kind of like chroot).
>
> I think it would be better to make a generic way to do this with user
> namespaces and mount namespaces and without this odd flag file. It may be
> useful for other filesystems within containers.
> (...)
'Mount namespace' is just a part of this patchset, the fact that cgroups are 
exported as a filesystems is 'on top', but we need to control everything 'from 
the bottom'.
For this to really work we have to guarantee that:
1. A task inside a container will never see that it's root cgroup is an 
'isolation root' either:
 a) via cgroupfs interface
 b) via /proc/[pid]/cgroup
2. A task inside an isolation root will not be able to leave the isolation 
root it's in
3. We have full control from the outside on the isolation root

The 'mount namespaces'/mounting 'with path' is a solution only to 1b, and even 
if it'd be implemented the fact is that I can't imagine any other situation 
where this would be useful .

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ