On Fri, 2004-10-29 at 10:31, Tom London wrote:

Running strict/enforcing off of Rawhide.

While doing today's rawhide installs (yum), I monitored the label of /etc/ld.so.cache via ls -lZ /etc/ld.so.cache

Several times during the installation of packages, the label of this file changed from system_u:object_r:ld_so_cache_t to root:object_r:ld_so_cache_t [OK, I think] or to root:object_r:etc_t [Not OK, I think]

Each time it changed to etc_t, I ran restorecon -vv /etc/ld.so.cache a few seconds later and got the typical restorecon reset context /etc/ld.so.cache->system_u:object_r:ld_so_cache_t

I'm guessing that when a package updates /etc/ld.so.cache, it may leave the label in a funny state, presuming that yum will fix it at the end.

Does this explain the 'intermittant' prelink error messages generated during package installations?

The problem is that ldconfig is presently being run in rpm_script_t rather than ldconfig_t, and thus /etc/ld.so.cache is not being labeled properly when it is re-created by ldconfig. ldconfig is run from %post as a helper. I provided a rpm_execcon() libselinux function to avoid this problem, but it isn't included in Fedora yet.

History of the problem is: 1) Originally, rpm only ran /bin/sh helpers in rpm_script_t; all others ran with default transitions, so ldconfig ran in ldconfig_t (as desired) but glibc_post_upgrade ran in rpm_t (and this ultimately led to sshd being run in rpm_t upon the /etc/init.d/sshd condrestart). 2) rpm was changed to run all helpers in rpm_script_t to avoid the glibc_post_upgrade problem. 3) ldconfig is now being run in rpm_script_t. Oops. 4) I created a rpm_execcon function that checks for a default transition for the helper and only sets explicitly to rpm_script_t if no automatic transition is defined. This puts ldconfig into ldconfig_t as desired and everything else in rpm_script_t.