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
|
