Running lorax in container and `container_file_t` contexts on installer image.

[rvykydal]

In Anaconda CI workflows we are running lorax in a container to build boot.iso images

• https://github.com/rhinstaller/anaconda/blob/87b3af4ad08d8855c9424f7faa24fd22635f67bb/.github/workflows/build-image.yml.j2#L231 or https://github.com/rhinstaller/anaconda/blob/87b3af4ad08d8855c9424f7faa24fd22635f67bb/Makefile.am#L422
• with this entry point: https://github.com/rhinstaller/anaconda/blob/main/dockerfile/anaconda-iso-creator/lorax-build

We are hitting an issue with container_file_t selinux context for a directory:

• the issue: reboot-initial-setup-{gui,tui} failing on rhel-9 anaconda PR test with "dasbus.error.DBusError: Failed to set X11 keyboard layout: Permission denied" rhinstaller/kickstart-tests#1607
• workaround PR: infra: Force restorecon on /etc/X11/xorg.conf.d for container iso builds rhinstaller/anaconda#6916.

@bcl do you have some hints how we could approach the issue?

• would it be possible to set up lorax somehow to restore context of installer image at the end ?
• or maybe rather to make sure the context is such that the relabeling at the end of Anaconda installation works ? - comparison to image not built in the container (nithtly iso) reboot-initial-setup-{gui,tui} failing on rhel-9 anaconda PR test with "dasbus.error.DBusError: Failed to set X11 keyboard layout: Permission denied" rhinstaller/kickstart-tests#1607 (comment)

[bcl]

The labels on the iso shouldn't have any effect since it is running in permissive mode. But we've seen similar problems before, https://issues.redhat.com/browse/CS-2788 has some details, and I think the root cause of that was systemd - https://issues.redhat.com/browse/RHEL-84905

[rvykydal]

I think we are hitting another issue, specifically related to running lorax in container. The problem is not the permissions during installation but permissions of configuration files on target system. I'll try to summarize the problem from the links in the first comment (where you can also look for details):

Running in container the image files/directories get
system_u:object_r:container_file_t:s0:c1022,c1023
while without container they get
system_u:object_r:var_lib_t:s0.

We are copying a config file from the installer image with this label to target system as part of configuration. At the end Anaconda restores context on specific path of target system to fix labels for this configuration modifications.
And this fails for the system_u:object_r:container_file_t:s0:c1022,c1023 with

`/etc/X11/xorg.conf.d/00-keyboard.conf not reset as customized by admin system_u:object_r:container_file_t:s0:c1022,c1023

restorecon on such file requires -F option.

So I am asking about a hint for running lorax in container, maybe

• we can run lorax in container in a way that would set context that is possible to update without forcing (I was trying to use --security-opt label=disable but it didn't work for me).
• or even try to restore the contexts at the end of image build but this seems to me maybe overly invasive

[rvykydal]

I am checking if the issue is triggered by our recent changes in running of the iso build container.
Does not seem so.

[rvykydal]

Installer tracks the issue here: https://issues.redhat.com/browse/INSTALLER-4609

[rvykydal]

A PR with potential solution on Anaconda side rhinstaller/anaconda#6927

[cgwalters]

Note this one strongly relates to rhinstaller/anaconda#5888 - if how we built the anaconda ISO was using bootc (and bootc-image-builder) we already handle SELinux labeling as part of bootc installs.