overlay.d: add 07fix-selinux-labels overlay #3150
Conversation
|
See https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/#_running_restorecon for why you should never run It's also part of the reasons that we made |
jbtrystram
force-pushed
the
fix-selinux-contexts
branch
from
6256bf8 to
ed706a5
Compare
|
Probably going to need to make this more complex unfortunately: coreos/fedora-coreos-tracker#1772 (comment) |
|
Let's focus on |
| find "$root_mount_point" -context '*:unlabeled_t:*' > "$unlabeled" | ||
|
|
||
| to_relabel=$(mktemp -d) | ||
| # filter out ostree repo objects |
There was a problem hiding this comment.
Instead of filtering, I would select only the files that we know we can safely relabel instead.
There was a problem hiding this comment.
Ideally we would call restorecon on those files instead of hardcoding a label in the script. But that might not work.
There was a problem hiding this comment.
IIUC we can't just call restorecon without having everything mounted in the right place, which we could do. i.e. on a running system sudo restorecon -vr /var/ /etc/ /usr/ /boot/ but that doesn't really handle some of the unlabeled files under /sysroot/ or /osree/ for which there isn't really any policy, which is kind of why we are in the mess we are in now.
I was thinking we could just find all files under / with unlabeled_t and make them root_t but I think @jlebon thought that wouldn't be safe.
There was a problem hiding this comment.
Ideally we would call restorecon on those files instead of hardcoding a label in the script. But that might not work.
there is no policy for files under /sysroot so that would not work
|
Here is what the root filesystem looks like after this script ran. |
| # Remove after the next barrier release | ||
|
|
||
| [Unit] | ||
| Description=Fix incorrect selinux labels under /boot and /sysroot |
There was a problem hiding this comment.
| Description=Fix incorrect selinux labels under /boot and /sysroot | |
| Description=CoreOS Fix SELinux Labels |
dustymabe
force-pushed
the
fix-selinux-contexts
branch
from
8b63bc1 to
72a5b0e
Compare
dustymabe
changed the title
|
I've updated this PR to fix existing FCOS and RHCOS systems and to include the tests from #3172 (which I'll now close in favor of this PR for those tests). |
dustymabe
force-pushed
the
fix-selinux-contexts
branch
from
72a5b0e to
98010fa
Compare
|
I think I've tested this enough now that I'm comfortable with it merging if it passes review. |
There was a problem hiding this comment.
Thanks @dustymabe for reworking that. Well documentend and easy to review !
I have just one concern about relabelling stuff in var
| /sysroot/ostree/repo/{.lock,config} \ | ||
| /sysroot/ostree/boot* \ | ||
| -context '*:unlabeled_t:*'; | ||
| find "/sysroot/" -maxdepth 7 -context '*:unlabeled_t:*' \ |
There was a problem hiding this comment.
This is going to go in the users' data in /sysroot/ostree/deploy/*/var directory. should we be concerned about relabelling files theres ?
There was a problem hiding this comment.
added a -prune to forcefully skip the var dir
overlay.d/07fix-selinux-labels/usr/libexec/coreos-fix-selinux-labels
Outdated
Show resolved
Hide resolved
dustymabe
force-pushed
the
fix-selinux-contexts
branch
3 times, most recently
from
b1336af to
20c266b
Compare
|
I can't approved my own PR, but LGTM ! |
|
I'll leave this open for a few more hours for further reviews. |
overlay.d/07fix-selinux-labels/usr/libexec/coreos-fix-selinux-labels
Outdated
Show resolved
Hide resolved
overlay.d/07fix-selinux-labels/usr/libexec/coreos-fix-selinux-labels
Outdated
Show resolved
Hide resolved
overlay.d/07fix-selinux-labels/usr/libexec/coreos-fix-selinux-labels
Outdated
Show resolved
Hide resolved
dustymabe
force-pushed
the
fix-selinux-contexts
branch
from
3924aa0 to
bf24565
Compare
The new name I think gives a better indication of what the test is doing.
/boot/efi and /sysroot dir and subfiles are unlabeled_t since 40.20240504.3.0. This is likely due to some missing scaffolding in the OSBuild software and definitions that we started using in [1]. These issues [2] [3] were addressed in [4] for new image builds, but we still need to fix upgrading systems, which we do here in this migration script. Note that we also fix a few files in /boot that were left unlabeled by `rdcore` [5] while we are in here. [1] coreos/fedora-coreos-tracker#1653. [2] coreos/fedora-coreos-tracker#1771 [3] coreos/fedora-coreos-tracker#1772 [4] coreos/coreos-assembler#3885 [5] coreos/fedora-coreos-tracker#1770 Co-authored-by: Dusty Mabe <[email protected]>
This adds a unlabeled and mislabeled files test and also adds code to the extended upgrade test to verify there aren't any suprises there either.
On every boot, the `/var/mnt` directory *in the deployment root* (i.e. not on top of any `/var` bind-mount/filesystem mount) would get recreated and be unlabeled. After a lot of digging and busting out systemtap, this turned out to be systemd doing this as part of switching root as a temporary mount point. In systemd v254+, this behaviour was changed to no longer require this directory: systemd/systemd@f2c1d49 For completeness, update the comment in this test to reflect these findings.
dustymabe
force-pushed
the
fix-selinux-contexts
branch
from
bf24565 to
8027ce9
Compare
/boot/efi and /sysroot dir and subfiles are unlabeled_t since
40.20240504.3.0.
This is likely due to a missing step in the OSBuild pipeline as this
started with coreos/fedora-coreos-tracker#1653.
This should be removed after the next barrier release, if the newly
produced images are fixed.
See coreos/fedora-coreos-tracker#1771
And coreos/fedora-coreos-tracker#1772