On 27.02.2014 16:32, Stephan Sachse wrote:
On Thu, Feb 27, 2014 at 3:07 PM, Dariusz Michaluk
<d.michaluk@xxxxxxxxxxx> wrote:
On 26.02.2014 17:59, Stephan Sachse wrote:
# chown -R foo:foo /var/lib/libvirt/filesystems/mycontainer
you must "shift" the uids for the container 0 -> 666, 1 -> 667, 2 ->
668. there is a tool for this: uidmapshift
I prepared two containers, the first I used chown, in the second
uidmapshift, here is the results.
./uidmapshift -r /var/lib/libvirt/filesystems/mycontainer
UIDs 666 - 666
GIDs 1001 - 2000
foo 28919 28917 0 14:42 ? 00:00:00 /sbin/init
747 28950 28919 0 14:42 ? 00:00:00 /bin/dbus-daemon
./uidmapshift -r /var/lib/libvirt/filesystems/test
UIDs 888 - 1776
GIDs 1002 - 2001
foo1 29298 29296 0 14:45 ? 00:00:00 /sbin/init
969 29329 29298 0 14:45 ? 00:00:00 /bin/dbus-daemon
As you can see root is mapped to foo or foo1 user and dbus user is mapped to
747 (uid=81(dbus) + uid=666(foo)) or 969 (uid=81(dbus) + uid=888(foo1)).
Mapping looks properly. Why use uidmapshift ?, it still performs chown.
Could you explain more?
# ls -ln uidmapshift-test/
-rw-r--r-- 1 0 0 0 27. Feb 15:50 uid0
-rw-r--r-- 1 81 81 0 27. Feb 15:50 uid81
# /root/uidmapshift -b uidmapshift-test/ 0 100000 1000
# ls -ln uidmapshift-test/
-rw-r--r-- 1 100000 100000 0 27. Feb 15:50 uid0
-rw-r--r-- 1 100081 100081 0 27. Feb 15:50 uid81
correctly mapped 0 to 100000 with a range of 1000
# chown 100000.100000 uidmapshift-test/ -R
# ls -ln uidmapshift-test/
-rw-r--r-- 1 100000 100000 0 27. Feb 15:50 uid0
-rw-r--r-- 1 100000 100000 0 27. Feb 15:50 uid81
wrong mapping for file uid81
look at the ls -l output from inside the container! btw:
/bin/dbus-daemon is root.root on my system (fedora20)
# rpm -qlv dbus | grep 'bin/dbus-daemon'
-rwxr-xr-x 1 root root 445104 Dez 26 10:26
/bin/dbus-daemon
fedora20 inside the container (999=ssh_keys)
# ls -ln /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 0 999 227 18. Feb 12:56 /etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 0 999 1679 18. Feb 12:56 /etc/ssh/ssh_host_rsa_key
fedora20 outside the container
ls -l etc/ssh/ssh_host_rsa_key etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 100000 999 227 18. Feb 13:56 etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 100000 999 1679 18. Feb 13:56 etc/ssh/ssh_host_rsa_key
i have a mapping: 0 to 100000 range 1
if the range is 10000. it must looks like this from the outside
ls -l etc/ssh/ssh_host_rsa_key etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 100000 100999 227 18. Feb 13:56 etc/ssh/ssh_host_ecdsa_key
-rw-r----- 1 100000 100999 1679 18. Feb 13:56 etc/ssh/ssh_host_rsa_key
and as before from the inside
some tools may not work, because of the missing file capabilities.
chown removes all file capabilities! try ping as user inside the
container. (missing file cap cap_net_admin,cap_net_raw)
# getcap /usr/bin/ping
# ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.077 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.066 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.066/0.071/0.077/0.010 ms
Yes you are right, chown removed capabilities, but ping still works
properly.
try it as user and not as root
# su -s/bin/bash nobody -c 'ping localhost'
ping: icmp open socket: Operation not permitted
fix this from outside the container
chroot /path/to/rootfs
rpm --qf "[%{FILECAPS} %{FILENAMES}\n]" -qa | grep ^= | sed -e 's/^=/setcap/'
and paste the output into your terminal
/stephan
Yes you are right, thank you for the clear and simple explanation, now I
understand.
--
Dariusz Michaluk
Samsung R&D Institute Poland
Samsung Electronics
d.michaluk@xxxxxxxxxxx
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
