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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
