RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1592775 - Failed to read //etc/selinux/targeted/policy/policy.31 policy file
Summary: Failed to read //etc/selinux/targeted/policy/policy.31 policy file
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Vit Mojzis
QA Contact: Milos Malik
Depends On:
TreeView+ depends on / blocked
Reported: 2018-06-19 09:50 UTC by aarora06
Modified: 2020-09-24 13:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-02-27 12:46:49 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description aarora06 2018-06-19 09:50:21 UTC
Description of problem:

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. When this command is executed: /usr/sbin/semanage permissive -l, the error is seen. Though this is not always reproducible.

Actual results:

ERROR: policydb version 31 does not match my version range 15-30
ERROR: Unable to open policy //etc/selinux/targeted/policy/policy.31.
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 32, in <module>
    import seobject
  File "/usr/lib/python2.7/site-packages/seobject/__init__.py", line 36, in <module>
    import sepolicy
  File "/usr/lib64/python2.7/site-packages/sepolicy/__init__.py", line 907, in <module>
    raise e
ValueError: Failed to read //etc/selinux/targeted/policy/policy.31 policy file

Expected results:

The semanage command should have executed successfully.

Additional info:

Somehow there are 2 policy files under /etc/selinux/targeted/policy: policy.30 and policy.31

rpm -qf policy.31
file /etc/selinux/targeted/policy/policy.31 is not owned by any package

rpm -qf policy.30

Comment 2 Vit Mojzis 2018-06-19 13:11:07 UTC
Thank you for reporting the issue, could you please provide us with versions of the following packages in your system?

$ rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*" "libsepol*" "libsemanage*"

Also please try to update libsepol and policycoreutils-python packages and see if the problem persists.

# yum update "libsepol*" "policycoreutils*"

Comment 3 aarora06 2018-06-19 13:34:59 UTC
(In reply to Vit  Mojzis from comment #2)
> Thank you for reporting the issue, could you please provide us with versions
> of the following packages in your system?
> $ rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*"
> "libsepol*" "libsemanage*"
> Also please try to update libsepol and policycoreutils-python packages and
> see if the problem persists.
> # yum update "libsepol*" "policycoreutils*"

rpm -qa "policycoreutils*" "setools*" "selinux-policy*" "libselinux*" "libsepol*" "libsemanage*"

Can you tell from the above versions itself about any problems? I don't want to disturb the test environment for now. Also, if I put the system in permissive mode, then above issue is not seen.

Comment 4 aarora06 2018-06-19 18:22:29 UTC
JFYI .. This is my chat on the selinux channel about this issue..

* Now talking on #selinux
* Topic for #selinux is: English channel about NSA Security Enhanced Linux. (Denna kanal engelsk, #linux.se e svensk.) Please be patient, we're not always here, but we do like to chat so hang around. FAQ: https://selinuxproject.org/page/FAQ | http://reddit.com/r/selinux
* Topic for #selinux set by pebenito!~pebenito@unaffiliated/pebenito (Wed Mar 14 05:59:56 2018)
<aarora06> Hi! I faced an issue on selinux on RHEL 7.3 x86_64 system. Please check this defect: https://bugzilla.redhat.com/show_bug.cgi?id=1592775.
<grift> you can either use audit or add aan auditallow rule
<aarora06> I researched a little about it and a similar defect was faced with policy.20 file some time ago. Basically, I can see policy.30 and policy.31 files under /etc/selinux/targeted/policy directory which is causing the issue. And this is very rarely reproducible.
<grift> aarora06; what answer are you looking for?
<grift> remove the policy.30 file then see if you can reproduce
<aarora06> grift: Do you know what can cause such an issue where 2 policy files are created on a system
<grift> yes upgrades
<aarora06> rpm -qf policy.31 --> /etc/selinux/targeted/policy/policy.31 is not owned by any package and rpm -qf policy.30 --> selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
<aarora06> So, policy.31 file is the extra one created
<grift> yes so i suppose userspace and kernel were upgraded but the policy package doesnt reflect it
<grift> aarora06: its ugly upgrade but i suppose you shouldnt be able to reproduce it when you remove policy.30
<grift> and i suppose selinux-policy packages need to be updated to reflect the policyversion update
<aarora06> ok .. so this can be due to an issue with the repo that is setup which contains related rpms right?
<grift> aarora06: yes i suppose it can
<grift> maybe the policy package wasnt upgrade in the same transaction as the userspace package and or kernel pacakge
<grift> aarora06: selinux is 3 componeents, the kernel, the policy and the utils and libs
<aarora06> hmm .. so what is meant by userspace package and kernel package? Are these some specifically named package needed by selinux-policy-targeted? I am not sure I understand that part..
<grift> so all need to be updated if theres a major version change to selinux
<grift> user space packages are like libselinux libsepol but also policycoreutils* libsemanage semanage etc
<grift> policy is selinux-policy*
<aarora06> ok..
<grift> so when theres a policy version bump (that signal that the kernel learned new selinux trichs( everything needs to be made aware (recompiled)
<aarora06> so this would be an issue with dependencies right? All rpms should have had proper requires part to handle this right?
<grift> and in your case it seems that your policy package was still unaware of it
<grift> i suppose yes
<aarora06> ok..
<grift> but if you remove the policy.30 then it should be ok
<grift> atleast semi-ok
<grift> and run semodule -B
<grift> it will recompile the policy.31
<aarora06> I think in this policy.31 file should be removed because it is not owned by any package in my case..
<aarora06> rpm -qf policy.31 --> /etc/selinux/targeted/policy/policy.31 is not owned by any package and rpm -qf policy.30 --> selinux-policy-targeted-3.13.1-102.el7_3.4.noarch
<grift> naw you wont be able to stop it from compiling the 31 anyway
<grift> everything uses 31 now except that selinux-policy package
<grift> so as soon as you do anything selinux is will compile 31
<grift> try it out
<aarora06> ok..
<grift> mv the policy.* files
<grift> then run semodule -B
<grift> and look in the dir
<grift> youll see that theres a policy.31
<grift> thats because the userspace will try to build the latest polvers
<aarora06> I will try that Thanks!
<grift> its just like you said, they should probably have some requires to make it consistent
<grift> but its easitly resolved just rm policy.30 && semodule -B
<grift> and then wait for an updates selinux-policy
<grift> updated
<aarora06> yes .. policy.31 got created
<grift> so its just that the selinux-policy package wasnt compiled against the new user space or that theres a bug in the spec file
<grift> probably the former
<aarora06> when would the former happen?
<grift> well when the kernel and selinux userspace are upgraded to a version that has new selinux features
<grift> but not the policy package
<grift> afaik its exactly as you said
<aarora06> yes .. but then this would again be an issue with spec file right? The spec file Requires should be responsible to make it consistent..
<grift> there probably should have been a require in the selinux user space to say, hey this update needs an updates selinux-policy
<aarora06> yes
<grift> yes thats how i see it
<aarora06> ok.. I will post this chat on that bug so that the redhat team looks into it this way
<grift> o theyll know
<aarora06> ok
<aarora06> thanks!
<grift> its a bit late now though and this wont happen again in the foreseeable future
<grift> arguable the bug is in semaange and whatever libs it uses
<grift> it should probably be smart enough to just pick the previous polvers
<grift> but even then ...
<grift> actually you can probably tell semanage to use 30
<grift> in /etc/selinux/targeted/semanage.conf
<grift> so that would have been another option
<grift> to just tell selinux, keep using version 30 regardless
<aarora06> ok.. how is that done
<grift> https://manpages.debian.org/testing/libsemanage-common/semanage.conf.5.en.html
<aarora06> Also is it "safe"/recommended to use..
<grift> policy-version When generating the policy, by default semanage will set the policy version to POLICYDB_VERSION_MAX, as defined in <sepol/policydb/policydb.h>. Change this setting if a different version needs to be set for the policy.
<grift> so i suppose echo "policy-version = 30" >> /etc/selinux/targeted/semanage.conf && semodule -B && ls -lh /etc/selinux/targeted/policy/
<grift> not recommended in general
<aarora06> Ok .. got that..
<grift> because if the policy would leverage a feature of polvers 31 then the compiler might tell you it doesnt know that feature i gather
<grift> gather
<aarora06> ok..
<aarora06> One more question: When using this command for regenerating the policy file - "semodule -B" -> Will this affect existing policies that user might have set for enforcing mode?
<aarora06> I guess it should..
<grift> no
<grift> its just recompiles the modules that are installed
<grift> ie it recompiles the policy.X file
<aarora06> ok .. so it is a harmless operation for a user using selinux?
<grift> so if you installed a .pp then that will be included as expected
<grift> yes
<aarora06> ok
<grift> its just like a "refresh"
<aarora06> Also, rpm -qf policy.31 -> file /etc/selinux/targeted/policy/policy.31 is not owned by any package -> Is this expected ? (This is after refresh..)
<grift> yes expected since its not owned by any package
<grift> policy.30 is
<aarora06> hmm.. 
<grift> so eventaully that will solve itself
<aarora06> why is there that difference..
<grift> once you update selinux-policy to a version that supports new user space
<grift> because selinux-policy you have installed , installed the old policy.30 file
<grift> but userspace wss upgraded and that compiles 31
<grift> so until you update to an selinux-policy that installs policy.31 youll get that
<grift> buts its just cosmetic
<grift> its an historicall thing
<grift> you see building that policy.X file takes some time
<grift> so to save time the selinux-policy package tries to copy a precompiled policy.X file
<grift> but that file only gets installed on new installation probably
<grift> so actually i really think its just a selinux-policy.spec bug
<grift> anyhow its no big deal
<aarora06> ok.. so to save time the selinux-policy package tries to copy a precompiled policy.X file --> and that is why it shows as being owned by selinux-policy-targeted..?
<grift> yes
<grift> if the package installs the file then it shows up in the rpm -qf
<grift> and in this case the policy.31 isnt installed by the package
<grift> its compiled with semodule -B, since you selinux-policy package still uses version 30 seemingly
<grift> but they will figure it out
<grift> just know that if you rm policy.30 and semodule -B, you should be fine
<aarora06> ok..
<grift> you dont even need to rm policy.30
<grift> just a semodule -B should do it
<aarora06> ok..

Comment 5 aarora06 2018-06-20 14:04:31 UTC
So, by refreshing the policy files by using this command : "semodule -B" and also updating the 2 packages mentioned in comment 2 : "libsepol*" "policycoreutils*" - the issue was resolved. 

To resolve this issue, Requires section should be appropriate for selinux packages in their spec files (such that only one policy file is generated).

Comment 6 aarora06 2018-06-29 11:35:31 UTC
Hi .. Is there a plan to fix this? Also, will that be in the next version or is the version with the fix is already out?

Comment 7 Kripa Shankar Sharma 2018-08-03 09:39:56 UTC
Is this defect resolve and out?

Comment 8 Vit Mojzis 2018-08-07 11:07:14 UTC
We are sorry, but the issue was not addressed yet. We improved the dependency chain in the latest versions of userspace and policy packages, but as of now we do not know what caused the partial update (updated userspace with old policy) in your system. Therefore we cannot be sure that the issue was resolved.
We will try to improve policy version handling in RHEL 7.7.

If you are not satisfied with this time frame, please escalate the issue via customer portal.

Comment 9 Kripa Shankar Sharma 2018-08-07 12:05:41 UTC
Thanks Mojzis. When is release date of RHEL 7.7. ?

Comment 10 Vit Mojzis 2018-08-08 14:14:21 UTC
That is not publicly available information.
Please see general guidelines regarding releases [1] or contact customer support for more information.

[1] https://access.redhat.com/support/policy/updates/errata/

Comment 11 Zdenek Pytela 2019-02-27 12:46:49 UTC
This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

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