How to access the Device Mapper from inside a Rootless user namespace?

[deomorxsy]

Hi! 👋 I am trying to understand this problem related to user namespace capabilities (I think): it seems it isn't related specifically with any OCI spec high-level container runtime, but with namespaces in general. I was wondering why I can't access the device-node/device-file of the Device Mapper under /dev/mapper/control, when calling kpartx -a to add all mappings. I am using unshare with the "-r" flag to map the root user, with a mount-namespace propagation=slave, then I create a nested mount-namespace with propagation=private. In both I am creating a new user namespace, which is the one that have capabilities tied to. I know there is also filesystem permissions to be considered, but does anyone here have any tips to how to solve this?

Running unshare with Rootfull privileges

; sudo unshare -r --user --mount --propagation=slave         --uts --ipc --net         --fork --pid         --mount-proc /bin/sh

Running unshare with Rootless privileges:

; unshare -r --user --mount --propagation=slave         --uts --ipc --net         --fork --pid         --mount-proc /bin/sh

Then, printing capabilities and id to get the real and effective user group:

; unshare -r --user --mount --propagation=slave \
        --uts --ipc --net \
        --fork --pid \
        --mount-proc \
        /bin/sh 
sh-5.2#
sh-5.2#
sh-5.2# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB:
Securebits: 00/0x0/1'b0 (no-new-privs=0)
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=65534(nobody),65534(nobody),0(root),65534(nobody),65534(nobody),65534(nobody),65534(nobody),65534(nobody)
Guessed mode: HYBRID (4)
sh-5.2#
sh-5.2# id
uid=0(root) gid=0(root) groups=0(root),65534(nobody)
sh-5.2#
sh-5.2#
sh-5.2#
sh-5.2#
sh-5.2# unshare --mount --propagation=private \
        --uts --ipc --net \
        --fork --pid \
        --mount-proc \
        /bin/sh
sh-5.2#
sh-5.2#
sh-5.2# id
uid=0(root) gid=0(root) groups=0(root),65534(nobody)
sh-5.2#
sh-5.2# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB:
Securebits: 00/0x0/1'b0 (no-new-privs=0)
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=65534(nobody),65534(nobody),0(root),65534(nobody),65534(nobody),65534(nobody),65534(nobody),65534(nobody)
Guessed mode: HYBRID (4)
sh-5.2#

Related to filesystem permissions, I also observed that:

Rootless can touch this:

; unshare -r --user --mount --propagation=shared         --uts --ipc --net         --fork --pid         --mount-proc /bin/sh
sh-5.2#
sh-5.2#
sh-5.2# touch hmmm.txt

...but Rootfull can't touch this. Also, since the parent namespace uses sudo, the capability holds.

; sudo unshare -r --user --mount --propagation=shared         --uts --ipc --net         --fork --pid         --mount-proc /bin/sh
[sudo] password for asari:
sh-5.2#
sh-5.2# touch hmmm.txt
touch: cannot touch 'hmmm.txt': Permission denied
sh-5.2#
sh-5.2# unshare --mount --propagation=private \
        --uts --ipc --net \
        --fork --pid \
        --mount-proc \
        /bin/sh
sh-5.2#
sh-5.2#
sh-5.2# touch hmmm.txt
touch: cannot touch 'hmmm.txt': Permission denied
sh-5.2#

by starting the first namespace unshare by using sudo, my understanding is that it will propagate to the child namespaces. (I think this term, propagate, is related only to mount, but I am also assuming it for the user namespaces.)

sh-5.2# kpartx -a ./artifacts/foo.qcow2
device-mapper: version ioctl on   failed: Permission denied
Incompatible libdevmapper 1.02.198 (2024-05-16) and kernel driver (unknown version).
device mapper prerequisites not met
sh-5.2#

While using Rootless, it returns:

sh-5.2# kpartx ./artifacts/foo.qcow2
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.198 (2024-05-16) and kernel driver (unknown version).
mount: could not find any device /dev/loop#
can't set up loop
sh-5.2#
sh-5.2#