#849552 policycoreutils: semodule aborts on corrupted installation, how can user solve this?

Package:
policycoreutils
Source:
policycoreutils
Description:
SELinux core policy utilities
Submitter:
Russell Coker
Date:
2021-03-05 09:12:04 UTC
Severity:
minor
Tags:
#849552#5
Date:
2016-12-28 14:56:16 UTC
From:
To:
After a system crash I found my policy database corrupted, here are some
examples:

# dpkg -i selinux-policy-default_2.20161023.1-5_all.deb
(Reading database ... 244796 files and directories currently installed.)
Preparing to unpack .../selinux-policy-default_2.20161023.1-5_all.deb ...
Unpacking selinux-policy-default (2:2.20161023.1-5) over (2:2.20161023.1-5) ...
Setting up selinux-policy-default (2:2.20161023.1-5) ...
Updating selinux default policy (this step might take a moment)...libsemanage.semanage_direct_get_module_info: Unable to read abrt module lang ext file.
semodule:  Failed on full!
libsemanage.semanage_direct_get_module_info: Unable to read abrt module lang ext file.
libsemanage.semanage_direct_get_module_info: Unable to read accountsd module lang ext file.
libsemanage.semanage_direct_get_module_info: Unable to read accountsd module lang ext file.
semodule:  Failed on /usr/share/selinux/default/abrt.pp.bz2!
 failed.
dpkg: error processing package selinux-policy-default (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 selinux-policy-default
# semodule -l
libsemanage.semanage_direct_get_module_info: Unable to read abrt module lang ext file.
semodule:  Failed on list!

Here is the tail end of stracing "semodule -l":
open("/var/lib/selinux/default/active/modules/100/abrt/lang_ext", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(4, "", 4096)                       = 0
write(2, "libsemanage.semanage_direct_get_"..., 45libsemanage.semanage_direct_get_module_info: ) = 45
write(2, "Unable to read abrt module lang "..., 41Unable to read abrt module lang ext file.) = 41
write(2, "\n", 1
)                       = 1
close(4)                                = 0
flock(3, LOCK_UN)                       = 0
close(3)                                = 0
write(2, "semodule:  Failed on list!\n", 27semodule:  Failed on list!
) = 27
exit_group(1)

I think that in this case semodule could reasonably recover from that situation
if we ran things properly.  But even in situations that it can't reasonably
recover from it should at least give a suggestion to the user as to what
they should do.

Maybe we need a semodule-recover script or something.

#849552#10
Date:
2021-03-05 09:08:52 UTC
From:
To:
severity 849552 minor
tags 849552 +moreinfo
thanks

Change the severity because it's not that important.  Also moreinfo because I
don't even know if that problem still happens or if it happens in the same
way.