Bug 182252 - /lib64 not searchable
/lib64 not searchable
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2006-02-21 09:10 EST by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-08 23:59:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2006-02-21 09:10:33 EST
Clean test3 install on ppc64.
dbus-daemon, gpm etc report failing to load libraries.

type=AVC msg=audit(1140530882.083:39): avc:  denied  { search } for  pid=2358
comm="gpm" name="lib64" dev=sda5 ino=979201 scontext=system_u:system_r:gpm_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(1140530882.083:39): arch=80000015 syscall=5 success=yes
exit=-13 a0=400000448a1 a1=0 a2=4000003a710 a3=8 items=1 pid=2358
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="gpm" exe="/usr/sbin/gpm"
type=CWD msg=audit(1140530882.083:39):  cwd="/"
type=PATH msg=audit(1140530882.083:39): item=0 name="/lib64/libm.so.6" flags=101
Comment 1 Daniel Walsh 2006-02-21 10:09:32 EST
This is a labeling problem.  Some how you have gotten files on your system
labeled as file_t?

This means you either ran with selinux=0 or you added a new disk which is not
labeled.

YOu can try restorecon -R -v /lib64

Or relabel the entire system

touch /.autorelabel
reboot
Comment 2 David Woodhouse 2006-02-21 10:11:09 EST
It was a clean install. This is reproduceable.
Comment 3 Daniel Walsh 2006-02-21 10:14:33 EST
Did you create /lib64 as a separate partition?

Dan
Comment 4 David Woodhouse 2006-02-21 10:19:30 EST
No. All one partition.
Comment 5 Paul Nasrat 2006-02-23 17:33:40 EST
rpm -qf /lib64
file /lib64 is not owned by any package

I bet this is as /lib64 is created as a side effect of the first file in there.
 We're not seeing on x86_64 as we probably have filesystem.x86_64 whereas on ppc
we have filesystem.ppc 
Comment 6 David Woodhouse 2006-03-03 08:53:31 EST
Still happening in today's rawhide
Comment 7 Paul Nasrat 2006-03-03 09:19:47 EST
Weren't we going to make filesystem biarch to fix this?  Else anaconda can
restorecon on /lib and /lib64
Comment 8 David Woodhouse 2006-03-06 18:57:10 EST
This one really needs to be fixed before FC5 final. The machine is fairly hosed
with selinux enabled.
Comment 9 Paul Nasrat 2006-03-06 20:55:36 EST
Bill, Jeremy views - pull in filesystem.ppc64 also on ppc distill or I can add
it do the list we restorecon in anaconda...
Comment 10 Jeremy Katz 2006-03-06 21:53:23 EST
Is it just /lib64 or is */lib64? 
Comment 11 Bill Nottingham 2006-03-06 23:16:46 EST
The restorecon is more portable (doesn't require distill hacks). Of course, it's
a hack itself.
Comment 12 Jeremy Katz 2006-03-06 23:51:46 EST
Okay, added the bad hack to anaconda to restorecon on /lib64 and /usr/lib64. 
Should be in rawhide tomorrow.  Paul -- can we make sure to check it on the g5
tomorrow.
Comment 13 Jakub Jelinek 2006-03-07 01:49:32 EST
Why can't filesystem.ppc include /lib64 as well (similarly to how
filesystem.ppc64 includes /lib)?
Comment 14 David Woodhouse 2006-03-07 05:04:32 EST
A pure 32-bit build shouldn't really create a /lib64 directory.

The problem here seems to be that /lib64 wasn't _explicitly_ created by any RPM;
it was automatically created by RPM. Why does this mean that it doesn't get
labelled? Should RPM handle automatic creation of directories differently?
Comment 15 David Woodhouse 2006-03-07 09:43:38 EST
rawhide-20060307 still fails -- /lib64 still isn't searchable.

In fact, today's rawhide seems to be a fairly significant regression in a bunch
of ways. DHCP no longer works -- I can see the DHCP response on the wire (from
another machine) but anaconda just goes straight back to the dialog bog asking
me for IP details, instead of giving any error message or (preferably) continuing.

If I set an IP address manually, the install works but then the system is
unbootable. It seems that it's caused by mount-by-label -- if I boot into rescue
mode and change to 'root=/dev/sda5' when it works. Otherwise I just get 'Error
mounting /dev/root on /sysroot as ext3: No such file or directory'. 

Having fixed that up, firstboot doesn't seem to run.
Comment 16 Peter Jones 2006-03-08 23:59:37 EST
Should be fixed now.

Note You need to log in before you can comment on or make changes to this bug.