SELinux-related Rawhide breakage today

[Jim Meyering]

Daniel J Walsh wrote:

> On 01/31/2012 12:07 PM, Jerry James wrote:
>> After installing today's Rawhide updates on an x86_64 VM, I
>> started having troubles running programs.  Nothing linked with
>> libselinux.so.1 could actually open that library; the programs were
>> getting EACCESS on the attempt.  I figured I needed to do a
>> relabel, but since restorecon is linked with libselinux.so.1,
>> .....
>>
>> I touched /.autorelabel and rebooted.  The system couldn't even
>> shut down, so I had to do a sync and a forced shutoff.  When the
>> system came back up, it immediately started complaining about lots
>> of programs that were unable to load libcrypt.  So I forced it off
>> again and rebooted with enforcing=0.  That worked, but skipped the
>> relabeling step!  I got a root shell and ran restorecon by hand to
>> relabel.  The only file that got relabeled was this, which looks
>> wrong:
>>
>> restorecon reset /lib64/libproc-3.2.8.so context
>> system_u:object_r:lib_t:s0->system_u:object_r:default_t:s0
>>
>> Is something broken in SELinux land today?
>
> Yes we have shipped a policy that requires the usrmove functionality.
>
> If you add
>
> /lib64 /lib
>
> to
>
> /etc/selinux/targeted/contexts/files/file_contexts.subs_dist
>
> Then run restorecon -R -v /lib64

Thanks for the heads up.
I had just pulled the latest updates and found that I couldn't
ssh to that box at all -- console didn't work, either.
Luckily I still had the root ssh session from which I'd done the update.

In it, I confirmed the "/lib64 /lib" line is already present in that
file, presumably since I've just updated, and did this to recover:

    setenforce 0
      restorecon -R -v /lib64
    setenforce 1

Without the "setenforce 0", restorecon would fail due to this:

    # restorecon -R -v /lib64
    restorecon: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory