Bug 145171 - init services fail because of glibc segment mapping permission problem
init services fail because of glibc segment mapping permission problem
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 17:49 EST by Gabriel Schulhof
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-15 12:35:08 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 Gabriel Schulhof 2005-01-14 17:49:18 EST
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 12:35:08 EST
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 13:37:29 EST
The above suggestion seems to work. Thanks !

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