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. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
