[libvirt-users] understanding --idmap for containers (v2.5.0)
Hello, I'm testing containers on a host machine without selinux so I'm trying use the idmap feature, but I must be missing something because all that I get is a readonly container for the root user. # virsh version --daemon Compiled against library: libvirt 2.5.0 Using library: libvirt 2.5.0 Using API: QEMU 2.5.0 Running hypervisor: QEMU 2.8.1 Running against daemon: 2.5.0 # virsh --connect lxc:/// dumpxml lab-gentoo-01 <domain type='lxc'> <name>lab-gentoo-01</name> <uuid>a9f73091-b716-4b61-95ad-fa1d0c061bef</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>2</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64'>exe</type> <init>/bin/sh</init> </os> <idmap> <uid start='0' target='900' count='10'/> <gid start='0' target='900' count='10'/> </idmap> <features> <privnet/> </features> <cpu mode='host-model'> <model fallback='allow'/> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/libvirt_lxc</emulator> <filesystem type='mount' accessmode='passthrough'> <source dir='/media/containers/lab-gentoo-01/'/> <target dir='/'/> </filesystem> <interface type='bridge'> <mac address='00:16:3e:c8:13:14'/> <source bridge='bridge-01'/> </interface> <console type='pty'> <target type='lxc' port='0'/> </console> </devices> </domain> # ls -l /media/containers/lab-gentoo-01/ total 36 drwxr-xr-x 2 root root 4096 Apr 13 07:33 bin drwxr-xr-x 2 root root 18 Apr 13 03:28 boot drwxr-xr-x 7 root root 4096 Apr 18 12:45 dev drwxr-xr-x 31 root root 4096 Apr 18 12:49 etc drwxr-xr-x 2 root root 18 Apr 13 03:28 home lrwxrwxrwx 1 root root 5 Apr 13 06:13 lib -> lib64 drwxr-xr-x 2 root root 4096 Apr 13 06:14 lib32 drwxr-xr-x 9 root root 4096 Apr 13 07:33 lib64 drwxr-xr-x 2 root root 18 Apr 13 03:28 media drwxr-xr-x 2 root root 18 Apr 13 03:28 mnt drwxr-xr-x 2 root root 18 Apr 13 03:28 opt drwxr-xr-x 2 root root 6 Apr 13 03:18 proc drwx------ 2 root root 18 Apr 13 03:28 root drwxr-xr-x 2 root root 31 Apr 13 07:32 run drwxr-xr-x 2 root root 4096 Apr 13 07:36 sbin drwxr-xr-x 2 root root 18 Apr 13 03:28 sys drwxrwxrwt 2 root root 18 Apr 13 07:36 tmp drwxr-xr-x 13 root root 4096 Apr 18 12:49 usr drwxr-xr-x 9 root root 102 Apr 13 03:28 var # virsh --connect lxc:/// start --console lab-gentoo-01 Domain lab-gentoo-01 started Connected to domain lab-gentoo-01 Escape character is ^] sh-4.3# /usr/bin/id uid=0(root) gid=0(root) groups=0(root) sh-4.3# pwd / sh-4.3# touch asdf touch: cannot touch 'asdf': Permission denied sh-4.3# indeed the container is using the idmap feature because the efective uid/gid map (900/900) is not allowing writes in the filesystem, but it doesn't seems very usefull. is it possible to have read/write containers while using idmap?
On Thu, Apr 20, 2017 at 08:26:11AM +0000, mailing lists wrote:
Hello, I'm testing containers on a host machine without selinux so I'm trying use the idmap feature, but I must be missing something because all that I get is a readonly container for the root user.
# virsh version --daemon Compiled against library: libvirt 2.5.0 Using library: libvirt 2.5.0 Using API: QEMU 2.5.0 Running hypervisor: QEMU 2.8.1 Running against daemon: 2.5.0
# virsh --connect lxc:/// dumpxml lab-gentoo-01 <domain type='lxc'> <name>lab-gentoo-01</name> <uuid>a9f73091-b716-4b61-95ad-fa1d0c061bef</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>2</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64'>exe</type> <init>/bin/sh</init> </os> <idmap> <uid start='0' target='900' count='10'/> <gid start='0' target='900' count='10'/>
Ok, so UID 0 in the container is being mapped to UID 900 in the host.
<filesystem type='mount' accessmode='passthrough'> <source dir='/media/containers/lab-gentoo-01/'/> <target dir='/'/> </filesystem>
# ls -l /media/containers/lab-gentoo-01/ total 36 drwxr-xr-x 2 root root 4096 Apr 13 07:33 bin drwxr-xr-x 2 root root 18 Apr 13 03:28 boot drwxr-xr-x 7 root root 4096 Apr 18 12:45 dev drwxr-xr-x 31 root root 4096 Apr 18 12:49 etc drwxr-xr-x 2 root root 18 Apr 13 03:28 home lrwxrwxrwx 1 root root 5 Apr 13 06:13 lib -> lib64 drwxr-xr-x 2 root root 4096 Apr 13 06:14 lib32 drwxr-xr-x 9 root root 4096 Apr 13 07:33 lib64 drwxr-xr-x 2 root root 18 Apr 13 03:28 media drwxr-xr-x 2 root root 18 Apr 13 03:28 mnt drwxr-xr-x 2 root root 18 Apr 13 03:28 opt drwxr-xr-x 2 root root 6 Apr 13 03:18 proc drwx------ 2 root root 18 Apr 13 03:28 root drwxr-xr-x 2 root root 31 Apr 13 07:32 run drwxr-xr-x 2 root root 4096 Apr 13 07:36 sbin drwxr-xr-x 2 root root 18 Apr 13 03:28 sys drwxrwxrwt 2 root root 18 Apr 13 07:36 tmp drwxr-xr-x 13 root root 4096 Apr 18 12:49 usr drwxr-xr-x 9 root root 102 Apr 13 03:28 var
THis is showing that the container's root filesystem is owned by UID 0 in the *host*.
# virsh --connect lxc:/// start --console lab-gentoo-01 Domain lab-gentoo-01 started Connected to domain lab-gentoo-01 Escape character is ^] sh-4.3# /usr/bin/id uid=0(root) gid=0(root) groups=0(root) sh-4.3# pwd / sh-4.3# touch asdf touch: cannot touch 'asdf': Permission denied
This is expected, because UID 0 in container is remapped to uid 900 in host, and is thus denied ability to write to a directory owned by uid 0 in the host
indeed the container is using the idmap feature because the efective uid/gid map (900/900) is not allowing writes in the filesystem, but it doesn't seems very usefull.
is it possible to have read/write containers while using idmap?
You need to change the UIDs in your container's filesystem to be offset by 900 Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thursday, April 20, 2017 10:44 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
indeed the container is using the idmap feature because the efective uid/gid map (900/900) is not allowing writes in the filesystem, but it doesn't seems very usefull.
is it possible to have read/write containers while using idmap?
You need to change the UIDs in your container's filesystem to be offset by 900
yes, that was my first thought but I was unsure if it was the correct way. running these commands did the trick (not all files are root:root): # find /media/containers/lab-gentoo-01 -uid 0 -exec chown --no-dereference 900 -- {} \;# find /media/containers/lab-gentoo-01 -gid 0 -exec chgrp --no-dereference 900 -- {} \; # ls -l /media/containers/lab-gentoo-01/ total 36 -rw-r--r-- 1 900 900 0 Apr 20 11:16 a drwxr-xr-x 2 900 900 4096 Apr 13 07:33 bin drwxr-xr-x 2 900 900 18 Apr 13 03:28 boot drwxr-xr-x 7 900 900 4096 Apr 18 12:45 dev drwxr-xr-x 31 900 900 4096 Apr 18 12:49 etc drwxr-xr-x 2 900 900 18 Apr 13 03:28 home lrwxrwxrwx 1 900 900 5 Apr 13 06:13 lib -> lib64 drwxr-xr-x 2 900 900 4096 Apr 13 06:14 lib32 drwxr-xr-x 9 900 900 4096 Apr 13 07:33 lib64 drwxr-xr-x 2 900 900 18 Apr 13 03:28 media drwxr-xr-x 2 900 900 18 Apr 13 03:28 mnt drwxr-xr-x 2 900 900 18 Apr 13 03:28 opt drwxr-xr-x 2 900 900 6 Apr 13 03:18 proc drwx------ 2 900 900 18 Apr 13 03:28 root drwxr-xr-x 2 900 900 31 Apr 13 07:32 run drwxr-xr-x 2 900 900 4096 Apr 13 07:36 sbin drwxr-xr-x 2 900 900 18 Apr 13 03:28 sys drwxrwxrwt 2 900 900 18 Apr 13 07:36 tmp drwxr-xr-x 13 900 900 4096 Apr 18 12:49 usr drwxr-xr-x 9 900 900 102 Apr 13 03:28 var # virsh --connect lxc:/// start --console lab-gentoo-01 Domain lab-gentoo-01 started Connected to domain lab-gentoo-01 Escape character is ^] sh-4.3# /usr/bin/id uid=0(root) gid=0(root) groups=0(root)sh-4.3# pwd / sh-4.3# ls -la total 40 drwxr-xr-x 21 root root 4096 Apr 20 10:36 . drwxr-xr-x 21 root root 4096 Apr 20 10:36 .. -rw------- 1 root root 45 Apr 20 11:15 .bash_history drwxr-xr-x 2 root root 6 Apr 18 13:41 .oldroot drwxr-xr-x 2 root root 4096 Apr 13 07:33 bin drwxr-xr-x 2 root root 18 Apr 13 03:28 boot drwxr-xr-x 3 root root 320 Apr 20 11:15 dev drwxr-xr-x 31 root root 4096 Apr 18 12:49 etc drwxr-xr-x 2 root root 18 Apr 13 03:28 home lrwxrwxrwx 1 root root 5 Apr 13 06:13 lib -> lib64 drwxr-xr-x 2 root root 4096 Apr 13 06:14 lib32 drwxr-xr-x 9 root root 4096 Apr 13 07:33 lib64 drwxr-xr-x 2 root root 18 Apr 13 03:28 media drwxr-xr-x 2 root root 18 Apr 13 03:28 mnt drwxr-xr-x 2 root root 18 Apr 13 03:28 opt dr-xr-xr-x 249 nobody nobody 0 Apr 20 11:15 proc drwx------ 2 root root 18 Apr 13 03:28 root drwxr-xr-x 2 root root 31 Apr 13 07:32 run drwxr-xr-x 2 root root 4096 Apr 13 07:36 sbin dr-xr-xr-x 12 nobody nobody 0 Mar 24 23:11 sys drwxrwxrwt 2 root root 18 Apr 13 07:36 tmp drwxr-xr-x 13 root root 4096 Apr 18 12:49 usr drwxr-xr-x 9 root root 102 Apr 13 03:28 var sh-4.3# touch asdfsh-4.3# Thank you Daniel !!
participants (2)
-
Daniel P. Berrange -
mailing lists