Bug 1765818 - Cannot longer install podman: error: Plugin selinux: hook fsm_file_prepare failed
Summary: Cannot longer install podman: error: Plugin selinux: hook fsm_file_prepare fa...
Alias: None
Product: Fedora
Classification: Fedora
Component: podman
Version: 31
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F30FailsToInstall
TreeView+ depends on / blocked
Reported: 2019-10-26 10:43 UTC by Miro Hrončok
Modified: 2022-04-19 17:32 UTC (History)
9 users (show)

Fixed In Version: podman-1.7.0-3.fc30 podman-1.7.0-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-01-10 01:13:40 UTC
Type: Bug

Attachments (Terms of Use)

Description Miro Hrončok 2019-10-26 10:43:59 UTC
At my recent dnf upgrade, podman transaction failed, I cannot longer install podman:

$ dnf install podman
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                                                         1/1 
  Installing       : podman-2:1.6.2-2.fc30.x86_64                                                                                                                                                                            1/1 
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package podman-2:1.6.2-2.fc30.x86_64
  Verifying        : podman-2:1.6.2-2.fc30.x86_64                                                                                                                                                                            1/1 


Error: Transaction failed

Comment 1 Miro Hrončok 2019-10-26 10:46:49 UTC
type=AVC msg=audit(1572086705.196:5948): avc:  denied  { mac_admin } for  pid=3665 comm="dnf" capability=33  scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2 permissive=0

Hash: dnf,unconfined_t,unconfined_t,capability2,mac_admin


Comment 2 Miro Hrončok 2019-10-26 18:48:05 UTC
On Fedora 31 I cannot longer reproduce this.

Comment 3 Daniel Walsh 2019-10-27 08:23:10 UTC
Miro, Did you remove container-selinux or something?  mac_admin means that dnf/rpm was attempting to put down a label that the kernel did not understand.
Podman executable is labeled based on the container-selinux package which should be installed before podman.

I would od

dnf reinstall container-selinux
dnf reinstall podman

And see if this cleans up the issue.

Comment 4 Miro Hrončok 2019-10-27 08:29:21 UTC
no, I was just running plain dnf upgrade. If there are some logs I can share, I will.

Comment 5 Miro Hrončok 2019-10-27 08:31:15 UTC
BTW this was not a regression in the new build, `dnf install 'podman < 2:1.6.2-2'`  failed in the same way with podman-2:1.2.0-2.git3bd528e.fc30.

Comment 6 Daniel Walsh 2019-10-27 08:40:15 UTC
Could you try the commands I listed above to see if the issue goes away.

Comment 7 Miro Hrončok 2019-10-27 08:52:48 UTC
Sorry, I cannot. I solved the problem by upgrading to Fedora 31. Feel free to close this, or I can provide more data from the logs, if there is something useful.

Comment 8 Tom Killian 2020-01-07 00:12:22 UTC
I ran into this error upgrading containers-common on an FC30 system.  Per this bugzilla, I installed container-selinux (it was not previously installed) and the problem went away.  Perhaps there is (or was) a missing dependency for container-selinux.

Comment 9 Jindrich Novy 2020-01-07 10:56:38 UTC
podman has container-selinux only as a soft dependency. I will turn it into a hard dep to be sure container-selinux is always installed prior to podman.

Comment 10 Miro Hrončok 2020-01-07 11:08:19 UTC
Maybe it can be conditionalized on selinux-policy?

  Requires:  (container-selinux if selinux-policy)

OTOH Im not sure if you can ever install podman without selinux-policy.

Comment 11 Jindrich Novy 2020-01-07 11:20:40 UTC
# rpm -q --requires container-selinux | grep selinux-policy
selinux-policy >= 3.14.4-43
selinux-policy-base >= 3.14.4-43
selinux-policy-targeted >= 3.14.4-43

so container-selinux already requires selinux-policy. The F30 spec file is way different than F31 (podman-remote subpackage missing, etc.) so I will leave it be for F30 and fix it for F31.

Comment 12 Miro Hrončok 2020-01-07 11:28:26 UTC
container-selinux already requires selinux-policy, but I proposed to only require container-selinux if selinux-policy is installed. That is completely orthogonal.

Imagine this scenario:

 1. selinux-policy is installed
 2. user installs podman
 3. container-selinux gets pulled in

And this scenario:

 1. selinux-policy is not installed, maybe this is a minimal container itself?
 2. user installs podman
 3. container-selinux does not get pulled in, and neither does selinux-policy

Anyway, I'm not sure "selinux-policy is not installed" is a realstic scenario.


Side note:

The error happens on transaction. The requires probably must be added as Requires(pre) and Requires(post) as well.

Comment 13 Jindrich Novy 2020-01-07 11:45:13 UTC
Miro - running podman without selinux-policy is more a question for Dan.

Dan, do you think scenario described by Miro would work? Meaning would it fly to run podman without selinux-policy in case of minimal containers?

Comment 14 Daniel Walsh 2020-01-07 17:53:52 UTC
I would prefer it stay a soft dependency for people wanting to run podman within a container.  Sucking in container-selinux pulls in selinux-policy and really swells the size of the container image.

Comment 15 Daniel Walsh 2020-01-07 17:55:24 UTC
Podman will run fine without selinux-policy.

If there is a construct in rpm to not install container-selinux is selinux-policy is not installed, I am fine with that.

Although for security in containers SELinux is the best tool that we have.

Comment 16 Miro Hrončok 2020-01-07 18:09:04 UTC
(In reply to Daniel Walsh from comment #15)
> If there is a construct in rpm to not install container-selinux is
> selinux-policy is not installed, I am fine with that.

There is:

Requires:  (container-selinux if selinux-policy)

Comment 17 Daniel Walsh 2020-01-07 23:02:20 UTC

Comment 18 Fedora Update System 2020-01-08 14:16:08 UTC
FEDORA-2020-9aae371366 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9aae371366

Comment 19 Fedora Update System 2020-01-09 01:07:48 UTC
podman-1.7.0-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9aae371366

Comment 20 Fedora Update System 2020-01-10 01:13:40 UTC
podman-1.7.0-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2020-01-10 02:09:42 UTC
podman-1.7.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 22 Dmitry Stremkouski 2022-04-19 17:32:38 UTC
In my case I have solved similar issue by grepping of broken label name (container_var_lib_t in my case), moving responsible binary policy file and reinstalling selinux-policy:

 1086  grep container_var_lib_t /etc/ -R # this pointed to /etc/selinux/targeted/contexts/files/file_contexts.bin as matching file.
 1087  dnf provides /etc/selinux/targeted/contexts/files/file_contexts.bin # checked which rpm provides it
 1088  mv /etc/selinux/targeted/contexts/files/file_contexts.bin /root/ # backing up
 1089  dnf reinstall selinux-policy-targeted # reinstalling the policy, post-install script will recompile removed binary policy file

This issue appeared after Fedora upgrade from 35 to 36, but I guess it is valid for any other release jump. Please update the doc, no need to reopen the ticket.

Note You need to log in before you can comment on or make changes to this bug.