On 28.01.2014 12:46, Daniel P. Berrange wrote:
On Tue, Jan 28, 2014 at 12:32:41PM +0100, Jan Olszak wrote:
Hi there!
I am trying to turn on user namespace by adding following lines to the
config:
<idmap>
<uid start='0' target='0' count='100000'/>
<gid start='0' target='0' count='100000'/>
</idmap>
As you can see the root in container is mapped to the root outside. I was
expected to see no difference after adding this lines, but unfortunately
there are some (see details below).
Am I missing something or is there a problem with system, libvirt or kernel?
I've not had any chance to try LXC + user namespaces + systemd yet, but
based on the list of things which fail, it seems like it might not be
detecting that it is inside a container. Seems almost like it has still
got the CAP_MKNOD permission and so is strying to start things it should
not have like udev, and various filesystems.
Daniel
I was able to reduce the problem by not using libvirt nor systemd.
I've created a bash process inside user namespace with mapping
root_inside<->root_outside.
I've used a program from https://lwn.net/Articles/532593/ :
./userns_child_exec -U -M '0 0 1' -G '0 0 1' bash
This program simply calls clone with CLONE_NEWUSER flag and set proper
uid_map and gid_map.
The test commands are as follows:
mkdir /test
mount debugfs /test -t debugfs
and strace shows:
mount("debugfs", "/test", "debugfs", MS_MGC_VAL, NULL) = -1 EPERM
(Operation not permitted)
Now the question is:
Is it a kernel bug or expected behavior ie. inside user namespace we
have always limited permissions even if uid=0 inside container is mapped
to uid=0 outside?
# cat /proc/$$/uid_map
0 0 1
# cat /proc/$$/gid_map
0 0 1
# cat /proc/$$/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
--
Piotr Bartosiewicz
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
