Bug 145171

Summary: init services fail because of glibc segment mapping permission problem
Product: [Fedora] Fedora Reporter: Gabriel Schulhof <gabrielschulhof>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-15 17:35:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gabriel Schulhof 2005-01-14 22:49:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.12

Description of problem:
When newly installed, FC3 booted without errors. However, after updating it via yum, we got the following errors upon reboot:

When booting, syslogd, ntpd, and portmap fail because of loader permission errors:

portmap: error while loading shared libraries: libnsl.so.1: failed to map segment from shared object: Permission denied

syslogd: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Permission denied

ntpd: error while loading shared libraries: libm.so.6: failed to map segment from shared object: Permission denied

Version-Release number of selected component (if applicable):
glibc-2.3.4-2.fc3

How reproducible:
Always

Steps to Reproduce:
1. Install FC3
2. Update via yum
3. Reboot
    

Actual Results:  syslogd et. al. fail to run because of shared library permission issues

Expected Results:  Flawless operation of all init scripts.

Additional info:

None

Comment 1 Jakub Jelinek 2005-01-15 17:35:08 UTC
This means that for some reason SELinux contexts of the libraries were messed
up.  The libraries (not the symlinks, just the regular files), like
/lib/tls/libc-2.3.4.so etc. should have all *shlib_t context, try ls -lZ
/lib/tls.
I certainly can't reproduce this here though, upgrade from FC3 glibc to FC3
update glibc went flawlessly here on countless boxes.

To fix this up, run
rpm -ql glibc | xargs restorecon
or something similar to fix up the contexts.

Comment 2 Gabriel Schulhof 2005-01-17 18:37:29 UTC
The above suggestion seems to work. Thanks !