SELinux messed up during version-upgrade: libsepol.permission_copy_callback
SELinux got somehow mangled during upgrade process from Fedora21 -> Fedora22. Some of the modules were changed between the versions and as a result my SELinux "system" is borked. It'd be nice to have more available documentation on re-installing and/or resetting SELinux on a system. I can't use any of the normal tools to manage SELinux, as it only prints out errors like libsepol.permission_copy_callback.... Attempting to relabel a filecontext, for example results in:
# semanage fcontext -a -t system_dbusd_var_lib_t /var/lib/dbus/machine-id
libsepol.context_from_record: type radicale_port_t is not defined (No such file or directory).
libsepol.context_from_record: could not create context structure (Invalid argument).
libsepol.port_from_record: could not create port structure for range 5232:5232 (tcp) (Invalid argument).
libsepol.sepol_port_modify: could not load port range 5232 - 5232 (tcp) (Invalid argument).
libsemanage.dbase_policydb_modify: could not modify record value (Invalid argument).
libsemanage.semanage_base_merge_components: could not merge local modifications into policy (Invalid argument).
OSError: Invalid argument
I've found 1 relevant bug related to something similar to my issue. The only "resolution" comes in the last comment from a user, though it's not very clear/detailed on the exact way of "fixing" this problem once and for all. Anyway, here's the relevant comment from the bug-report:
Robin Powell 2015-06-22 15:20:04 EDT
Umm, sure, and the obvious way to rebuild them is to delete them using semanage, which I can't do. Just rebuilding them is tricky because I use a puppet module for the builds and I haven't done one by hand in ages; I guess I could make a one character change to all my modules to make them regen?
Ah, here we go.
So for everybody else: what I did was find all the .pp files (i.e. sudo find /etc | grep my | grep -v mysql | grep -v mythtv | grep '.pp' or whatever works for you) and then simply deleted them (i.e. sudo rm /etc/selinux/mymodules/mypuppetedit/mypuppetedit.pp /etc/selinux/mymodules/myvirshbugs880971/myvirshbugs880971.pp ...).
After puppet rebuilt them, everything is fine. I dunno about NOTABUG. IMO, semanage not being able to remove invalid modules is absolutely a bug. But at least I have a workaround.
- I've already tried relabeling the system with
# touch /.autorelabelmultiple times - I've tried removing the pertinent lines that are reported as irrelevant during relabel from the file in
/etc/selinux/targeted/modules/active/file_contexts.localwithout any changes - I've tried disabling SELinux via
/etc/selinux/configand/or kernel commandline withselinux=0in hopes that re-enabling it would, somehow, magically fix the issue; alas, no dice - I've tried removing the
selinux-policy\*packages while disabled one by one with# rpm -ev selinux... --nodepsand reinstalling them; again, no dice
Once again, the linked bug report is marked as NOTABUG; I have to ask at this point, what is it then? I am clearly not the only one affected by this.
The frustrating thing is that I did not notice/experience this issue ...
That is not typical when upgrading, I have not seen this problem. I would re-install the selinux policy.
@bodhi.zazen, What's the correct way of reinstalling the
selinux-policy? I've tried to do that, as you can see in my question.Upgrades of any OS are nor guaranteed to go without problems. With all the time you have spent on this, you almost certainly could have done a fresh install by now. Also, the reasoning for closing as "NOT A Bug" were given to you by the volunteers who maintain the package. My best advice at this point is to advise you to do a fresh install.
Once again: What's the correct way of reinstalling the selinux-policy? I've tried to do that, as you can see in my question.