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