Control: tag -1 moreinfo confirmed
I could reproduce this, but only in a bullseye chroot build
environment with a running buster (4.19) kernel. I haven't tried with
a bullseye kernel + bullseye chroot.
The build log in the bug report states similarly:
Kernel: Linux 4.19.0-6-cloud-amd64 #1 SMP Debian 4.19.67-2+deb10u2
(2019-11-11) amd64 (x86_64)
I'd also like to point out this snippet from the ERRORS section of the
manpage for unshare(2):
EPERM (since Linux 3.9)
CLONE_NEWUSER was specified in flags and the caller is
in a chroot environment (i.e., the caller's root direc‐
tory does not match the root directory of the mount
namespace in which it resides).
This is important because the test suite executes /bin/unshare with -r
in firehol-3.1.6+ds/tests/tools/newns which then calls
unshare(CLONE_NEWUSER):
$ strace -e trace=unshare unshare -r unshare -n -m /bin/date
unshare(CLONE_NEWUSER) = 0
unshare(CLONE_NEWNS|CLONE_NEWNET) = 0
In fact under all kernels I've tried (4.19, 5.10) this command even
when run as root always fails with "Operation not permitted":
chroot /chrootenvdir /bin/unshare -r /bin/date
My understanding of the interaction of chroot and
unshare(2)/namespaces in general is incomplete, but this to me
indicates the test suite of firehol in its current form simply cannot
be run in a chroot environment (at least on 4.19 kernels, but probably
also later ones) and should be disabled until the unshare backend for
sbuild has matured enough to be used on the build servers.
@Jerome: Could you try to get someone from either the Debian Kernel
Team or the sbuild maintainers to take a look at this? If you get no
answer there then make sure notify the release team as they may have
to waive this one.
Regards,
Dennis.
