FAQ
Hi.

CentOS 5.4 64-bit with SELinux, happily running for over a year, suddenly
httpd fails to start up, getting an error message like:

Starting httpd: Syntax error on line X of /etc/httpd/conf.d/php.conf:
Cannot load /etc/httpd/modules/libphp5.so into server: libxml2.so.2:
failed to map segment from shared object: Permission denied

I turned off SELinux and was able to start httpd.

But what went wrong? And how to fix it and turn SELinux back on?

SElinux labels on libxml.so.2.6.26 are OK ( system_u:object_r:lib_t )
and "restorecon -n libxml.so.2.6.26" does not return anything.

No recent AVC denied entries in /var/log/audit/audit.log or /var/log/messages.

I googled the above error message but all I could find were web pages in Chinese
advising to run restorecon on libxml2.so file or turn off SElinux.

Any suggestions?

Thanks
Aleksey

Search Discussions

  • Kwan Lowe at Mar 25, 2010 at 3:14 am

    On Wed, Mar 24, 2010 at 10:49 PM, Aleksey Tsalolikhin wrote:
    Hi.

    CentOS 5.4 64-bit with SELinux, happily running for over a year, suddenly
    httpd fails to start up, getting an error message like:

    Starting httpd: Syntax error on line X of /etc/httpd/conf.d/php.conf:
    Cannot load /etc/httpd/modules/libphp5.so into server: libxml2.so.2:
    failed to map segment from shared object: Permission denied

    I turned off SELinux and was able to start httpd.

    But what went wrong? ?And how to fix it and turn SELinux back on?

    SElinux labels on libxml.so.2.6.26 are OK ( system_u:object_r:lib_t )
    and "restorecon -n libxml.so.2.6.26" does not return anything.

    No recent AVC denied entries in /var/log/audit/audit.log or /var/log/messages.

    I googled the above error message but all I could find were web pages in Chinese
    advising to run restorecon on libxml2.so file or turn off SElinux.
    There was a thread awhile back:
    http://lists.centos.org/pipermail/centos/2010-January/088551.html

    Sounds like similar issues.. No AVC denials but blocking...
    Thanks
    Aleksey
    _______________________________________________
    CentOS mailing list
    CentOS at centos.org
    http://lists.centos.org/mailman/listinfo/centos
  • Kahlil Hodgson at Mar 25, 2010 at 3:21 am

    On 03/25/2010 01:49 PM, Aleksey Tsalolikhin wrote:
    CentOS 5.4 64-bit with SELinux, happily running for over a year, suddenly
    httpd fails to start up, getting an error message like:
    ...
    I turned off SELinux and was able to start httpd.

    But what went wrong? And how to fix it and turn SELinux back on?
    What went wrong? You might want to start by getting a bound on _when_
    it went wrong. When was the last time you successfully started httpd?
    The problem happened sometime after that. Look in your logs for any
    suspicious events. Check /var/log/yum.log. Any new packages? Did a
    yum transaction fail (postinstall might be tinkering with SElinux)?
    Try "yum-complete-transaction". Any configuration changes since then?
    Starting httpd: Syntax error on line X of /etc/httpd/conf.d/php.conf:
    Cannot load /etc/httpd/modules/libphp5.so into server: libxml2.so.2:
    failed to map segment from shared object: Permission denied
    Might want to try "restorecon -rv /etc/httpd" as well.

    Kal
    --
    Kahlil (Kal) Hodgson GPG: C37B01F4
    Head of Technology (m) +61 (0) 4 2573 0382
    DealMax Pty Ltd (w) +61 (0) 3 9008 5281

    Suite 1005
    401 Docklands Drive
    Docklands VIC 3008 Australia

    "All parts should go together without forcing. You must remember that
    the parts you are reassembling were disassembled by you. Therefore,
    if you can't get them together again, there must be a reason. By all
    means, do not use a hammer." -- IBM maintenance manual, 1925
  • Alexander Kirillov at Mar 25, 2010 at 7:49 am

    CentOS 5.4 64-bit with SELinux, happily running for over a year, suddenly
    httpd fails to start up, getting an error message like:

    Starting httpd: Syntax error on line X of /etc/httpd/conf.d/php.conf:
    Cannot load /etc/httpd/modules/libphp5.so into server: libxml2.so.2:
    failed to map segment from shared object: Permission denied

    I turned off SELinux and was able to start httpd.

    But what went wrong? And how to fix it and turn SELinux back on?

    SElinux labels on libxml.so.2.6.26 are OK ( system_u:object_r:lib_t )
    and "restorecon -n libxml.so.2.6.26" does not return anything.

    No recent AVC denied entries in /var/log/audit/audit.log or /var/log/messages.
    Try to turn off the dontaudit rules for domains
    that are in the base policy:

    semodule -b /usr/share/selinux/targeted/enableaudit.pp

    Then you might see the denials in the logs and fix the problem
    in your local policy.

    HTH
  • Aleksey Tsalolikhin at Mar 28, 2010 at 6:18 am

    On Thu, Mar 25, 2010 at 12:49 AM, A. Kirillov wrote:
    CentOS 5.4 64-bit with SELinux, happily running for over a year, suddenly
    httpd fails to start up, getting an error message like:

    Starting httpd: Syntax error on line X of /etc/httpd/conf.d/php.conf:
    Cannot load /etc/httpd/modules/libphp5.so into server: libxml2.so.2:
    failed to map segment from shared object: Permission denied

    I turned off SELinux and was able to start httpd.

    But what went wrong? ?And how to fix it and turn SELinux back on?

    SElinux labels on libxml.so.2.6.26 are OK ( system_u:object_r:lib_t )
    and "restorecon -n libxml.so.2.6.26" does not return anything.

    No recent AVC denied entries in /var/log/audit/audit.log or /var/log/messages.

    OK, here's what happened:

    We had added /opt/PostgreSQL/8.4/lib to LD_LIBRARY_PATH in
    /etc/profile as we wanted our in-house python daemon to use PostgreSQL 8.4
    client as we were seeing memory leak using 8.1 but not 8.4.

    Turned out there was a libxml2.so.2 in the PostgreSQL lib directory
    and the httpd was trying
    to pick it up instead of /usr/lib64/libxml2.so.2, and failing as it
    had a "usr_t" instead of "lib_t" label.

    [root at hwd-ddc-app01-prod01 modules]# ldd /etc/httpd/modules/libphp5.so
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b9640e52000)
    libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x00002b964108a000)
    libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x00002b964135a000)
    libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00002b964155c000)
    libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b9641795000)
    libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00002b96419d2000)
    libz.so.1 => /usr/lib64/libz.so.1 (0x00002b9641be3000)
    libpcre.so.0 => /lib64/libpcre.so.0 (0x00002b9641df7000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b9642013000)
    libm.so.6 => /lib64/libm.so.6 (0x00002b9642229000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002b96424ac000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b96426b0000)

    libxml2.so.2 => /opt/PostgreSQL/8.4/lib/libxml2.so.2
    (0x00002b96428c9000) <----- our culprit

    libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
    (0x00002b9642b08000)
    libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b9642d36000)
    libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b9642fcc000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b96431f1000)
    libssl.so.6 => /lib64/libssl.so.6 (0x00002b96433f3000)
    libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b964363e000)
    libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b964398f000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b9643bc0000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b9643f18000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b9644218000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003c3e000000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
    (0x00002b9644427000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b964462f000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b9644832000)
    libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b9644a4a000)
    [root at hwd-ddc-app01-prod01 modules]# ls -l /opt/PostgreSQL/8.4/lib/libxml2.so.2
    -rwxr-xr-x 1 root daemon 4115398 Dec 10 02:41
    /opt/PostgreSQL/8.4/lib/libxml2.so.2
    [root at hwd-ddc-app01-prod01 modules]# ls -lZ /opt/PostgreSQL/8.4/lib/libxml2.so.2
    -rwxr-xr-x root daemon user_u:object_r:usr_t
    /opt/PostgreSQL/8.4/lib/libxml2.so.2
    [root at hwd-ddc-app01-prod01 modules]#

    I fixed this by adding "unset LD_LIBRARY_PATH" to /etc/init.d/httpd. Now we load
    /usr/lib64/libxml2.so.2 which has the correct label (lib_t)

    I think I'll change this by moving the LD_LIBRARY_PATH setting from /etc/profile
    into the startup script for the python daemon, so I can have a vanilla
    /etc/init.d/httpd

    Thank you very much for your help!
    Aleksey

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedMar 25, '10 at 2:49a
activeMar 28, '10 at 6:18a
posts5
users4
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase