This message was deleted.
# rke2
a
This message was deleted.
r
There's an RPM that is supposed to get installed to push those policies. Maybe that install got stalled/horked? I don't recall the name of it any more, but it used to be a separate manual step but I'm told isn't any more.
l
I've tried reinstalling (and a remove-reboot-install) the container-selinux and rke2-selinux packages a few times, and it doesn't seem to have helped unfortunately. I can see the SELinux module for rke2 seems to be loaded, inspecting the container via crictl seems to be asking for the right labels, and relabeling doesn't seem to want to do anything
r
I don't remember how to inspect the config. Did you install with RPM or TAR version of the install (Rancher deploy does TAR)? I know a year and a half ago when RKE2 SELinux was still experimental, the TAR version did not work, primarily because it put some of the files in different locations than the RPM, and the policies in rke2-selinux were expecting things to be where the RPM put them.
l
RPM install, with the get.rke2.io script
r
Only idea I have left is you could install setroubleshootd (and maybe another related tool, not certain), turn SELinux permissive and then use it's help to figure out what to force as a policy to get the failure to stop.
I remember the first time I had to deal with SELinux on a RHEL 5 system they had included some handy tools to scan the audit log and give you commands to permanently allow the behavior that was part of the failure. It had a component that ran in X so when logged in graphically it'd give a notification of the failure.
l
Yeah, I know why SELinux is denying it, it doesn't like a container_t touching a var_lib_t, I just don't know why the container filesystem isn't getting labeled correctly as a container_ro_file_t
r
What I remember of the setroubleshoot tools it'd give you commands to create and persist a policy for the specifics of the error. The fact that I used that saved me lots of time but also left me not as aware of the internals of the policy settings since I just used the auto tools.
l
Yeah, I'd ideally like to not poke holes in SELinux as a workaround, I'd like to know why the relabel isn't taking place
r
Hard to say. I think I recall if you turn SELinux to disabled and reboot it'll remove all labels on all files, so then when you set it back to enforcing it has to relabel the entire file system.
But if restorecon & .autorelabel & whatnot aren't working, that's the only possibly larger hammer I can think of.
You could also compare working nodes by trying to check the SELinux context containerd is running under. Supposedly
ps --context
shows that, but when I tried it also seemed to make -ef just show my current session as a tree instead of all system processes.
Poking around in proc, it looks like
/proc/${PID}/attr/current
and/or
/proc/${PID}/attr/prev
seem to hold the SELinux context of the process. I assume current is right?