prelink and yum conflict

[Tom London]

I've been running this system strict/enforcing most of the time
(running strict/permissive when the policy is wedged).

After 'yum update' a few days ago, after observing the
'prelink messages' noted above, lots of stuff started
breaking, like gconftool-2, gnome-terminal, bononbo-activation-server,
etc.  Each would fail with segmentation faults.

These could all be repaired by reinstalling the 'appropriate'
package (e.g., GConf2, gnome-terminal, libbonobo, ....) via
'rpm -ivh --force yum-cached-package'

Following a suggestion from fedora-test-list, I started running
'rpm -V' (in permissive mode) on my installed packages. Many of these
fail, e.g.:

libuser
S.?......   /usr/bin/lchfn
S.?......   /usr/bin/lchsh
S.?......   /usr/lib/libuser.so.1.1.1
S.?......   /usr/sbin/lchage
S.?......   /usr/sbin/lgroupadd
S.?......   /usr/sbin/lgroupdel
S.?......   /usr/sbin/lgroupmod
S.?......   /usr/sbin/lid
S.?......   /usr/sbin/lnewusers
S.?......   /usr/sbin/lpasswd
S.?......   /usr/sbin/luseradd
S.?......   /usr/sbin/luserdel
S.?......   /usr/sbin/lusermod

each with a line like:
prelink: /usr/lib/liblwres.so.1.1.2: at least one of file's
dependencies has changed since prelinking
prelink: /usr/bin/dig: at least one of file's dependencies has changed
since prelinking
prelink: /usr/bin/host: at least one of file's dependencies has
changed since prelinking
prelink: /usr/bin/nslookup: at least one of file's dependencies has
changed since prelinking
prelink: /usr/bin/nsupdate: at least one of file's dependencies has
changed since prelinking

(there are scads of these, picked this one at random.
Sorry, the first set of messages not coordinated with second.).

I can 'make these go away' by reinstalling via 
'rpm -ivh --force yum-cached-package', and then
'rpm -V' succeeds with no messages.

Could yum/rpm/prelink be scribbling?  Or am I chasing
shadows?

tom

On Mon, 11 Oct 2004 08:39:30 -0400, Jeff Johnson <n3npq at nc.rr.com> wrote:
> Russell Coker wrote:
> 
> >On Sat, 9 Oct 2004 02:14, Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> >
> >
> >>/etc/ld.so.cache is supposed to be labeled ld_so_cache_t.
> >>
> >>
> >
> >ldconfig is being executed directly from rpm not via "sh -c ldconfig".  This
> >means that it doesn't transition to ldconfig_t.
> >
> >Jeff, please change rpm to use "sh -c" for spawning all scripts including
> >ldconfig and /usr/sbin/glibc_post_upgrade.  Should I file a bugzilla against
> >rpm?
> >
> I would if it would "work".
> 
> This was my reasoning originally for limiting "rpm_script_t" to /bin/sh
> execution, rather than
> applying in general.
> 
> As long as glibc_post_upgrade is a static binary that attempts sshd
> restart, policy
> will be a bit more complex than otherwise. The restart of sshd is necessary
> iff there is a incompatibility in one of the name service modules, a fairly
> rare event.
> 
> Making glibc_post_upgrade actions a bit easier to see and change is
> needed imho.
> I'd suggest using the embedded lua now in rpm rather than the a
> statically linked
> helper. But that is probably a different problem than /etc/ld.so.cache
> mentioned here.
> 
> Current behavior is to set "rpm_script_t" for all package interpreters
> rather than
> just /bin/sh.
> 
> What change(s) do you wish?
> 
> 73 de Jeff
> 
> 
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
> 


-- 
Tom London