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@xxxxxxxxx> wrote: > Russell Coker wrote: > > >On Sat, 9 Oct 2004 02:14, Stephen Smalley <sds@xxxxxxxxxxxxxx> 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@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London
