Mock in Docker container fails: "Insufficient rights." (with --privileged/--cap-add=SYS_ADMIN permissions)

[dreibh]

Short description of the problem

Running "mock -h" inside a "fedora:40" or "fedora:latest" Docker container (with --privileged/--cap-add=SYS_ADMIN) since a few days just prints "Insufficient rights.", without any further useful information. Mock worked before, also in GitHub Actions. There is probably a recent change, or a recent configuration update of Fedora, breaking Mock in containers.

Output of rpm -q mock

mock-5.9-1.fc40.noarch

Steps to reproduce issue

1. docker run --cap-add=SYS_ADMIN --privileged --rm -it fedora:latest bash
2. dnf install -y mock
3. mock -h
   The output is always: "Insufficient rights."

Any additional notes

Output of mock --debug-config:

Insufficient rights.

[dreibh]

Using the "fedora:39" container works fine, i.e. the issue is related to Fedora 40. The version of Mock in Fedora 39 is the same:

[root@ecb8a5f27055 /]# cat /etc/fedora-release 
Fedora release 39 (Thirty Nine)
[root@ecb8a5f27055 /]# rpm -q mock
mock-5.9-1.fc39.noarch
[root@ecb8a5f27055 /]# mock -h
usage: 
       mock [options] {--init|--clean|--scrub=[all,chroot,cache,root-cache,c-cache,yum-cache,dnf-cache,lvm,overlayfs]}

[dreibh]

This is the end of the strace output of the Mock run on Fedora 40. It may help to locate the problem:

newfstatat(AT_FDCWD, "/etc/login.defs", {st_mode=S_IFREG|0644, st_size=8888, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/etc/login.defs", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=8888, ...}) = 0
read(3, "#\n# Please note that the paramet"..., 4096) = 4096
read(3, "ID_MIN                  1000\nUID"..., 4096) = 4096
brk(0x597831d81000)                     = 0x597831d81000
read(3, " line length in the\n# group file"..., 4096) = 696
read(3, "", 4096)                       = 0
close(3)                                = 0
newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=639, ...}, 0) = 0
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1033, ...}) = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "root:x:0:0:Super User:/root:/bin"..., 4096) = 1033
close(3)                                = 0
pipe2([3, 4], 0)                        = 0
rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7244fb985710}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7244fb6c7b10) = 315
close(4)                                = 0
wait4(315, [{WIFEXITED(s) && WEXITSTATUS(s) == 9}], 0, NULL) = 315
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=315, si_uid=0, si_status=9, si_utime=0, si_stime=0} ---
read(3, "-1\n", 31)                     = 3
read(3, "", 28)                         = 0
close(3)                                = 0
rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7244fb985710}, NULL, 8) = 0
socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_AUDIT) = 3
sendto(3, [{nlmsg_len=140, nlmsg_type=0x44d /* NLMSG_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}, "\x6f\x70\x3d\x50\x41\x4d\x3a\x61\x63\x63\x6f\x75\x6e\x74\x69\x6e\x67\x20\x67\x72\x61\x6e\x74\x6f\x72\x73\x3d\x3f\x20\x61\x63\x63"...], 140, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 140
poll([{fd=3, events=POLLIN}], 1, 500)   = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, nlmsg_seq=2, nlmsg_pid=314}, {error=0, msg={nlmsg_len=140, nlmsg_type=0x44d /* AUDIT_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}}], 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 36
recvfrom(3, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, nlmsg_seq=2, nlmsg_pid=314}, {error=0, msg={nlmsg_len=140, nlmsg_type=0x44d /* AUDIT_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}}], 8988, MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 36
close(3)                                = 0
munmap(0x7244fb660000, 16392)           = 0
munmap(0x7244fb65a000, 20488)           = 0
munmap(0x7244fb652000, 28680)           = 0
munmap(0x7244fb64d000, 16392)           = 0
munmap(0x7244fb63d000, 61480)           = 0
munmap(0x7244fb632000, 29864)           = 0
munmap(0x7244fb602000, 195416)          = 0
munmap(0x7244fb5ae000, 342832)          = 0
munmap(0x7244fb4e6000, 815888)          = 0
munmap(0x7244fb4cf000, 90160)           = 0
munmap(0x7244fb4c8000, 24640)           = 0
munmap(0x7244fb4b8000, 62096)           = 0
munmap(0x7244fb4b1000, 24584)           = 0
munmap(0x7244faff3000, 71816)           = 0
munmap(0x7244fafcd000, 16392)           = 0
munmap(0x7244fafc8000, 16392)           = 0
munmap(0x7244fafc0000, 28960)           = 0
munmap(0x7244fafb5000, 40968)           = 0
munmap(0x7244fafb0000, 16392)           = 0
munmap(0x7244fafa8000, 28680)           = 0
munmap(0x7244faf1e000, 562072)          = 0
munmap(0x7244faedc000, 28680)           = 0
write(2, "Insufficient rights.\n", 21Insufficient rights.
)  = 21
exit_group(6)                           = ?
+++ exited with 6 +++

[praiskup]

Thank you for the report. But I can not reproduce this with moby-engine-27.3.1-2.fc41.src.rpm.

Is this a failure of consolehelper? Can you check if it is an SUID binary?

[root@a0ff81e77885 /]# ls -alh /usr/sbin/userhelper 
-rws--x--x. 1 root root 48K Jul 20 00:00 /usr/sbin/userhelper

[yrashk]

I have the same issue – worked a few days before.

ls -alh /usr/sbin/userhelper 
-rws--x--x 1 root root 48K Jul 20 00:00 /usr/sbin/userhelper

[yrashk]

I may have found an answer: this was a new cluster/node and it had AppArmor enabled. Disabling it on the node and rebooting it cleared the problem. I am not very well-oriented in AppArmor, but I wonder if there's a less radical solution (tuning vs turning it off).

Either way, doesn't seem to be a mock problem, at least in my case.

[madonuko]

I think it'd make sense to improve the error message since "Insufficient rights." doesn't directly help with finding out what the issue is at all.