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(a)epoch.ncsc.mil>
National Security Agency