On Tue, Feb 08, 2011 at 08:58:24PM -0600, Serge E. Hallyn wrote:
Until now, user namespaces have not done much, but (for that
reason) have been innocuous to glob in with other CLONE_
flags. Upcoming userns development, however, will make tasks
cloned with CLONE_NEWUSER far more restricted. In particular,
for some time they will be unable to access files with anything
other than the world access perms.
This patch assumes that noone really needs the user namespaces
to be enabled. If that is wrong, then we can try a more
baroque patch where we create a file owned by a test userid with
700 perms and, if we can't access it after setuid'ing to that
userid, then return 0. Otherwise, assume we are using an
older, 'harmless' user namespace implementation.
Comments appreciated. Is it ok to do this?
Given what you describe on the UserNamespaces wiki page I believe
this is the right thing todo in libvirt. There's no compelling
reason why we were setting this flag in the first place, other
than the fact that it existed & was thought todo something.
Signed-off-by: Serge Hallyn <serge.hallyn(a)canonical.com>
---
src/lxc/lxc_container.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 876bc62..a735eb7 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -810,7 +810,14 @@ static int lxcContainerChild( void *data )
static int userns_supported(void)
{
+#if 1
+ /*
+ * put off using userns until uid mapping is implemented
+ */
+ return 0;
+#else
return lxcContainerAvailable(LXC_CONTAINER_FEATURE_USER) == 0;
+#endif
}
ACK
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|