1. Please describe the problem: overlay mounts from a user namespace don't work when a context= option is specified. There is a patch accepted into selinux/next but it won't hit a release until 5.13, thus blocking us from testing rootless containers with native overlay mounts: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git/commit/?h=next&id=7fa2e79a6bb924fa4b2de5766dab31f0f47b5ab6 2. What is the Version-Release number of the kernel: 5.11.7-300.fc34.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: $ cat test.c #include <sys/mount.h> int main() { mount ("overlay", "merged", "overlay", 0, "lowerdir=l,workdir=w,upperdir=u,context=\"system_u:object_r:container_file_t:s0\""); return 0; } $ mkdir l w u merged $ gcc -o test test.c $ unshare -rm strace -f -e mount /tmp/cc mount("overlay", "merged", "overlay", 0, "lowerdir=l,workdir=w,upperdir=u,"...) = -1 EACCES (Permission denied) +++ exited with 0 +++ 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: no 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
We would really like to get this into peoples hands so we could test it before we put it in RHEL8.5 in the fall.
I think I'm hitting this as well. I'm using a user namespace, I need the context= option to be supplied otherwise the overlay file system gets the context of my user, "unconfined_u:unconfined_r:unconfined_t" which prevents from executing binaries hosted on the overlay file system. See reproducer below: 1. Create a minimal environment suitable to be chroot'ed into (user) $ sudo dnf install --installroot=$PWD/miniroot --releasever=/ bash (user) $ unshare -Urm (fakeroot) # id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 (fakeroot) # mkdir /tmp/foo 2. Mount the overlay without context= option: prevents from chroot'ing (fakeroot) # mount -t overlay overlay -o lowerdir=$PWD/miniroot:/mnt /tmp/foo (fakeroot) # ls -Z /tmp/foo/bin/bash unconfined_u:object_r:unconfined_t:s0 /tmp/foo/bin/bash (fakeroot) # chroot /tmp/foo chroot: failed to run command ‘/bin/bash’: Permission denied 3. Move to Permissive and retry to collect all the AVCs (root) # setenforce 0 (fakeroot) # chroot /tmp/foo (chroot) bash-5.1# exit (root) # ausearch -m avc -ts recent ---- time->Wed Jun 2 07:55:40 2021 type=AVC msg=audit(1622613340.469:1549): avc: denied { execute } for pid=14674 comm="chroot" name="bash" dev="overlay" ino=793408 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_t:s0 tclass=file permissive=1 ---- time->Wed Jun 2 07:55:40 2021 type=AVC msg=audit(1622613340.469:1550): avc: denied { execute_no_trans } for pid=14674 comm="chroot" path="/usr/bin/bash" dev="overlay" ino=793408 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_t:s0 tclass=file permissive=1 ---- time->Wed Jun 2 07:55:40 2021 type=AVC msg=audit(1622613340.469:1551): avc: denied { map } for pid=14674 comm="bash" path="/usr/bin/bash" dev="overlay" ino=793408 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_t:s0 tclass=file permissive=1 (fakeroot) # umount /tmp/foo 4. Mount the overlay with context= option: doesn't work (fakeroot) # mount -t overlay overlay -o lowerdir=$PWD/miniroot:/mnt,context=system_u:object_r:tmp_t:s0 /tmp/foo mount: /tmp/foo: cannot mount overlay read-only. Strace shows: 15115 08:02:59.951282 mount("overlay", "/tmp/foo", "overlay", MS_RDONLY, "lowerdir=/home/rmetrich/miniroot:/mnt,context=\"system_u:object_r:tmp_t:s0\"") = -1 EACCES (Permission denied) <0.000100> dmesg shows: SELinux: security_context_str_to_sid() failed for (dev overlay, type overlay) errno=-22
Now that the patch is accepted upstream, I have cherry-picked it back to the 5.12 branch for Fedora, this should appear in 5.12.9 and newer kernels.
Hi Justin, Do you know if that will also fix the issue that arises when not using "context=" option: overlay mount shows labels of the process ("unconfined_X") which is non-sense for files. See my comment " 2. Mount the overlay without context= option: prevents from chroot'ing " Renaud.
FEDORA-2021-c2b2f23a6f has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2b2f23a6f
FEDORA-2021-21f80017d0 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-21f80017d0
FEDORA-2021-c2b2f23a6f has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c2b2f23a6f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2b2f23a6f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-21f80017d0 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-21f80017d0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-21f80017d0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-21f80017d0 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-c2b2f23a6f has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
5.12.9-300.fc34.x86_64 works just fine for me: contexts appear properly.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days