Bug 1969996

This is fixed in container-selinux-2.162.2

Setting to Post and assigning to Jindrich for any packaging needs.

Could you run `restorecon -R -v /home` And see if labels change?  Then attempt to run podman.

restorecon works. Sorry I missed this step last time.
Server one without restorecon:
ls -lZd .local/share/containers/storage/overlay*
drwx------. 8 weshen weshen unconfined_u:object_r:data_home_t:s0 4096 Jun 18 07:30 .local/share/containers/storage/overlay
drwx------. 2 weshen weshen unconfined_u:object_r:data_home_t:s0   52 Jun 18 07:30 .local/share/containers/storage/overlay-containers
drwx------. 3 weshen weshen unconfined_u:object_r:data_home_t:s0  116 Jun 18 07:28 .local/share/containers/storage/overlay-images
drwx------. 2 weshen weshen unconfined_u:object_r:data_home_t:s0 4096 Jun 18 07:30 .local/share/containers/storage/overlay-layers
Server two with restorecon:
ls -lZd .local/share/containers/storage/overlay*
drwx------. 9 weshen weshen unconfined_u:object_r:container_ro_file_t:s0 4096 Jun 18 04:41 .local/share/containers/storage/overlay
drwx------. 2 weshen weshen unconfined_u:object_r:data_home_t:s0           52 Jun 18 04:41 .local/share/containers/storage/overlay-containers
drwx------. 4 weshen weshen unconfined_u:object_r:container_ro_file_t:s0  188 Jun 18 04:41 .local/share/containers/storage/overlay-images
drwx------. 2 weshen weshen unconfined_u:object_r:container_ro_file_t:s0 4096 Jun 18 04:41 .local/share/containers/storage/overlay-layers

After restorecon podman can build the image successfully.
[weshen@hp-dl380-gen9-3 ~]$ podman --cgroup-manager cgroupfs build .
STEP 1: FROM quay.io/cockpit/registry:2
STEP 2: RUN ls
bin
dev
entrypoint.sh
etc
home
lib
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
STEP 3: COMMIT
--> 3ccdd792a7e
3ccdd792a7ed4ff965e5849714bc52572d07b834d98585c6a72905b58f3fe773

I think if this is a fresh install it should work.  If you did an upgrade it will not.

The Fedora rpm has a relabel of the /home directory in the postinstall

Jindrich can you copy the trigger from contianer-selinux spec for Fedora Rawhide into the one for RHEL9.

If someone is updating from RHEL8, we might need this.

https://src.fedoraproject.org/rpms/container-selinux/c/2e560c5e4950e6c22b5acb055dd3769bfbfbc248 is quite a nasty hack Dan :) If container-selinux is getting upgraded in 8.4.0 to container-selinux = 2:2.162.1-3 or higher this trigger will no longer execute while upgrading to RHEL9. This will absolutely happen as there will be (at least) container-selinux = 2:2.163.0-1 in 8.4.0.2. The same logic applies to Fedora.

Is there any way to detect this issue in the regular %post scriptlet? In such case we don't need any triggers/version dependencies.

If not, we need to hardcode container-selinux version in the trigger upon RHEL9 GA when it will be clear which version of container-selinux will be there and we need to be always sure the version in RHEL8 is lower than in RHEL9, i.e. matching the trigger condition. This is very fragile unless e.g. there will be container-selinux 3.0.0 in RHEL9 and RHEL8 will always be kept at 2.x.y with upstream maintenance branch for it.

If I am running a newer version of container-selinux then 2:2.162.1-3  that means the relabel has already happened and never needs to happen again.

Newer users of podman/container-selinux will get the labeling correct.  So this is only an upgrade issue from the older container-selinux policies which
did not label the content in the homedir the way newer versions of container-selinux expect.

No reason to worry abour different versions in RHEL9 versus RHEL8 for this labeling since I want them to be consistent as much as possible.

@jnovy are you set with this based on Dan's comment?

Ok, I modified the logic so that it runs only once upon upgrade from RHEL8->9. To distinguish upgrade and regular update in RHEL9 I bumped Epoch in RHEL9. The trigger now looks like this:

%triggerpostun -- container-selinux < 3:2.162.1-3
if %{_sbindir}/selinuxenabled ; then
  echo "Fixing Rootless SELinux labels in homedir"
  %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay*  2> /dev/null || :
fi

(note the version in the trigger is not really relevant as only the Epoch matters)

I added the "|| :" at the end of restorecon so that %triggerpostun can never fail, otherwise it'd break the whole transaction leaving the system in the inconsistent state.

I tested the upgrade and update scenario and it works as expected.

Lokesh, do you mind modifying the trigger in Fedora like this so that it actually works there too?

Jindrich

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days