systemd-nspawn fails to mount /sys/fs/selinux in the container after dcff2fa #16032
Comments
We mount it into the contain in read-only fashion. That tells the payload that while selinux is available it shouldn't make use of it. i.e. the libselinux libraries explicitly check for the R/O status of selinuxfs, and understand that read-only means "existant, but not managed by us". Hiding selinuxfs in the container entirely doesn't really work, as the fact that selinux is there is leaked all over the place in /proc. Moreover PID 1 generally assumes that what isn't mounted already it needs to mount itself, and we like if we can keep the same codepaths in place when systemd runs in a container and on bare metal. Hence instead of not mounting selinuxfs (so that PID 1 would then try to mount it) we do pre-mount it but mark it read-only, so that we explicitly communicate that the container payload should not mount it, but also not manage it. |
|
Hmm, I don't see this with the lastest git (and neither systemd-245.5-2.fc33.x86_64). What command are you running exactly? In what mode is selinux on the host? |
Since systemd#15533 we didn't create the mount point for selinuxfs anymore. Before it we created it twice because we mount selinuxfs twice: once the superblock, and once we remount its bind mound read-only. The second mkdir would mean we'd chown() the host version of selinuxfs (since there's only one selinuxfs superblock kernel-wide). The right time to create mount point point is once: before we mount the selinuxfs. But not a second time for the remount. Fixes: systemd#16032
|
Fix waiting in #16194 |
Since #15533 we didn't create the mount point for selinuxfs anymore. Before it we created it twice because we mount selinuxfs twice: once the superblock, and once we remount its bind mound read-only. The second mkdir would mean we'd chown() the host version of selinuxfs (since there's only one selinuxfs superblock kernel-wide). The right time to create mount point point is once: before we mount the selinuxfs. But not a second time for the remount. Fixes: #16032
Since systemd#15533 we didn't create the mount point for selinuxfs anymore. Before it we created it twice because we mount selinuxfs twice: once the superblock, and once we remount its bind mound read-only. The second mkdir would mean we'd chown() the host version of selinuxfs (since there's only one selinuxfs superblock kernel-wide). The right time to create mount point point is once: before we mount the selinuxfs. But not a second time for the remount. Fixes: systemd#16032 (cherry picked from commit 6fe01ce)
Since systemd#15533 we didn't create the mount point for selinuxfs anymore. Before it we created it twice because we mount selinuxfs twice: once the superblock, and once we remount its bind mound read-only. The second mkdir would mean we'd chown() the host version of selinuxfs (since there's only one selinuxfs superblock kernel-wide). The right time to create mount point point is once: before we mount the selinuxfs. But not a second time for the remount. Fixes: systemd#16032 (cherry picked from commit 6fe01ce)
systemd version the issue has been seen with
Used distribution
Unexpected behaviour you saw
Steps to reproduce the problem
After upgrading to systemd-245.6-1.fc32.x86_64 which includes the fix for #15475: dcff2fa, the
/sys/fs/selinuxdirectory is no longer created in the container and the above errors are logged.While unrelated, the container still shows SELinux as being disabled -- so if containers aren't able to support SELinux inside, why bind mount this directory at all (just a question--I really don't know)?
Inside the container...
The text was updated successfully, but these errors were encountered: