Bug 182252 - /lib64 not searchable
Summary: /lib64 not searchable
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
 
Reported: 2006-02-21 14:10 UTC by David Woodhouse
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-09 04:59:37 UTC
Type: ---


Attachments (Terms of Use)

Description David Woodhouse 2006-02-21 14:10:33 UTC
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 15:09:32 UTC
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 15:11:09 UTC
It was a clean install. This is reproduceable.

Comment 3 Daniel Walsh 2006-02-21 15:14:33 UTC
Did you create /lib64 as a separate partition?

Dan

Comment 4 David Woodhouse 2006-02-21 15:19:30 UTC
No. All one partition.

Comment 5 Paul Nasrat 2006-02-23 22:33:40 UTC
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 13:53:31 UTC
Still happening in today's rawhide

Comment 7 Paul Nasrat 2006-03-03 14:19:47 UTC
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 23:57:10 UTC
This one really needs to be fixed before FC5 final. The machine is fairly hosed
with selinux enabled.

Comment 9 Paul Nasrat 2006-03-07 01:55:36 UTC
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-07 02:53:23 UTC
Is it just /lib64 or is */lib64? 

Comment 11 Bill Nottingham 2006-03-07 04:16:46 UTC
The restorecon is more portable (doesn't require distill hacks). Of course, it's
a hack itself.

Comment 12 Jeremy Katz 2006-03-07 04:51:46 UTC
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 06:49:32 UTC
Why can't filesystem.ppc include /lib64 as well (similarly to how
filesystem.ppc64 includes /lib)?

Comment 14 David Woodhouse 2006-03-07 10:04:32 UTC
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 14:43:38 UTC
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-09 04:59:37 UTC
Should be fixed now.


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