Description of problem: When upgrading the package on a newly installed system, never having run any containers, upgrade scriptlet failure occurs. It doesn't affect subsequent running of containers, but may cause intended labling changes to fail if there are multiple user home directories. Version-Release number of selected component (if applicable): container-selinux-2:2.162.2-2.fc33.noarch How reproducible: 100% Steps to Reproduce: 1. Install podman and container-selinux-2:2.160.2-1.fc33.noarch 2. Upgrade to container-selinux-2:2.162.2-2.fc33.noarch Actual results: ``` [root@localhost ~]# dnf upgrade ...big list of download URLs... ...cut... Running scriptlet: container-selinux-2:2.162.2-2.fc33.noarch 4/8 Upgrading : container-selinux-2:2.162.2-2.fc33.noarch 4/8 Running scriptlet: container-selinux-2:2.162.2-2.fc33.noarch 4/8 Deprecated, use selabel_lookup Cleanup : container-selinux-2:2.160.2-1.fc33.noarch 5/8 Running scriptlet: container-selinux-2:2.160.2-1.fc33.noarch 5/8 Fixing Rootless SELinux labels in homedir warning: %triggerpostun(container-selinux-2:2.162.2-2.fc33.noarch) scriptlet failed, exit status 255 Error in <unknown> scriptlet in rpm package container-selinux ``` Expected results: No errors Additional info: First discovered in https://bodhi.fedoraproject.org/updates/FEDORA-2021-0c53d8738d
This can probably be ignored, but I would love to know why it failed? Does this system have any homedirs? Any users?
One user, one homedir. My main concern (not knowing how the scriptlet works) is if there are 50 local users, the scriptlet fails after the 3rd one, will it still process the remaining 47?
This is what the scriptlet is doing. echo "Fixing Rootless SELinux labels in homedir" %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay* 2> /dev/null BTW For f33 this is probably not needed unless a really new kernel gets back ported to it.
Can you run this command on the host to see if it shows an error? I guess we could add a %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay* 2> /dev/null || true To basically ignore errors.
Thanks, that's enough information to poke around some more. Assuming this is bash or similar, I believe it enumerates the wild-card paths _before_ calling the command with them as parameters. So ignoring the error might be bad - the restorecon won't run at all, and the reason why is hidden. But I'm a bit fuzzy on this area of shell operations, I'll need to play with it to be sure...
...update: Bash seems to try and expand some wildcards, passing the rest into to the command. In the case of non-existent files/directories, they're left up to the command to handle them internally. So for this specific failure, it's the `restorecon` behavior with bad files that's important. In other words, does it just throw an error but keep changing things, or does it completely give up at the first problem?
I have no idea.
Idea: Perhaps using the find command would be more reliable here. Something like (untested) `find /home -path '*/.local/share/containers/storage/overlay*' -execdir %{_sbindir}/restorecon -R '{}' +`
It's fine, I'm just spit-balling. I'll grab a VM and play with it more tomorrow, now that I know more what's under the covers.
Well crud...I'm unable to reproduce any errors at all running the 'restorecon' command manually. I even tried doing some "evil things" like making a '/home/user/.local/share/containers/storage' file (normally it's a directory) then setting it immutable (chattr +i). The only case where it fails is if _NO_ home directories contain container storage: # restorecon -R /home/*/.local/share/containers/storage/overlay* restorecon: SELinux: Could not get canonical path for /home/*/.local/share/containers/storage/overlay* restorecon: No such file or directory. So, I'm confident that the error is harmless. I'll play around with my find command idea, maybe it can be used instead of just ignoring _ALL_ errors (since some may be helpful/useful)...
...okay all done playing. This seems to work well in my (manual) testing of the (equivalent) command: %{_bindir}/find /home -maxdepth 6 -type d -path '*/.local/share/containers/storage/overlay*' -exec %{_sbindir}/restorecon -i -R '{}' + I tested F34 with 7 home directories, with both no '.local/share/containers/storage' anywhere, and then with one of the users having done a 'podman run...' command. In all cases 'restorecon' is called with the minimal number of directories to fix (recursively) - including zero. No non-zero exit codes are returned in any case tested. Note: There are some corner-cases where this conversion will fall short. For example, on systems that have some/all users outside of /home or are using autofs (for example). Similarly, it will probably throw a hissy-fit if /home is an NFS or SMB mount (for example). It's also going to silently break if any user has $XDG_DATA_HOME set (for example in .bashrc) and pointing elsewhere. I can't think of any uncomplicated workarounds/fixes for any of those. This may cause non-trivial problems for support to diagnose for RHEL customers. Perhaps it would be a nice favor if we helped support craft a KB article on this? Does podman/buildah throw an error or would there be an AVC denial if some directory isn't labeled correctly?
`find /home` makes me a little queasy: it can hang catastrophically over NFS, and doesn't account for home directories outside of `/home` nor for users with a nonstandard graphRoot. In my email of May 17 I suggested: awk -F: -v cstorage=/.local/share/containers/storage '$7 !~ /nologin/ {if (system("test -d " $6 cstorage)==0) {print $6 cstorage}}' </etc/passwd ...but I don't like that either (it, too, ignores nonstandard graphRoot). Honestly, I think the least-worst solution is to `2>/dev/null` in the restorecon.
> the least-worst solution is to `2>/dev/null` in the restorecon. That's what we do today - it both doesn't fix the problem, and it hides the cause. See bug description. A proper "stick head in sand" fix would be more like Dan's idea: restorecon ... 2> /dev/null || true We can address all the corner cases with a simple KB article including the typical error/AVC message.
Tested, this works: %{_sbindir}/restorecon -R /home/*/.local/share/containers/storage/overlay* &> /dev/null || true
FEDORA-2021-143ad819a6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-143ad819a6
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.