Description of problem: As far as I can see, any upgrade of glibc is modifying the SELinux context of /usr/lib/gconv/gconv-modules.cache which can be verified this way: Fix file context by hand or do "touch /.autorelabel && reboot". Update glibc or use --force for updating: > rpm -V glibc ........C /usr/lib/gconv/gconv-modules.cache > > ls -l /usr/lib/gconv/gconv-modules.cache -rw-r--r-- 1 root root 25460 May 25 23:11 /usr/lib/gconv/gconv-modules.cache > > ls -Z /usr/lib/gconv/gconv-modules.cache -rw-r--r-- root root user_u:object_r:lib_t /usr/lib/gconv/gconv- modules.cache > > rpm -qi glibc | grep Install Install Date: Thu May 25 23:10:57 2006 Build Host: tux > Version-Release number of selected component (if applicable): glibc-2.4.90-10 How reproducible: Everytime, see above. Actual results: Incorrect SELinux context of /usr/lib/gconv/gconv-modules.cache most of the time when not relabeling the whole system or fixing by hand. Expected results: Correct SELinux context of /usr/lib/gconv/gconv-modules.cache ;-) Additional info: I don't know maybe this bug report has to be re-assigned to a SELinux component, but glibc update is causing this reproducable for me.
At least on FC5 I have installed glibc-post-upgrade.{x86_64,i686} creates the cache with user_u:object_r:lib_t and that's what restoreconf keeps it at.
The problem here is that rpm should be ignoring the SELinux user componant of the security context.
Ignoring? Describe the conditions necessary for deterministic behavior in rpm please.
In SELinux terms the files SELinux user is the user who created it "user_u", or the system default "system_u". So when you relabel the system the context gets reset to system_u, which matches exacly what is in the file_contexts file. When the file gets created via a user (root) it gets labeled user_u, (Or root, sysadm_u, staff_u ...) Depending on which SELinux user created. So since RPM can not tell the difference, the user componant of the SELinux context should be ignorred for this check.
Hmmm, that reads like Please ignore the wizard behind the screen. hand waving to me, YMMV, certainly seems to. I have not the foggiest idea under what conditions the user component should be ignored, and we seem to agree "RPM can not tell the difference." There are two non-wonderland fixes that I can see: 1) Create the file from packaging with "system_u" so relabel changes nothing. That implementation should happen in policy, seems like it is already there. 2) Change the lazy creation of the file so that the file is "system_u", not "user_u", when created. Neither 1) or 2) is a rpm problem.
Hey folks, why can't we simply get SELinux out of RPM? Dlopen() it or whatever fits and it will get a libselinux bug like #193489 which really has to be fixed within libselinux and not by hacking ugly things in RPM... ;-)
I agree remove the rpm -V functionality for SELInux and use restorecon and friends to verify the file context.
*** Bug 193489 has been marked as a duplicate of this bug. ***
As far as I can see, verify of SELinux contexts has been removed in Rawhide by rpm-4.4.2-noselinux-verify.patch used in rpm-4.4.2-25, thanks.