I compiled PHP version 5.0.3 from source obtained from php.net on a Pentium 4 system running Fedora Core 3 and this message appears in /var/log/messages after httpd starts:
audit(1106189173.206:0): avc: denied { execute } for pid=3999 path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file
/usr/lib/20041030/ldap.so is a PHP "extension". How can I fix this problem and allow the extension execute permission?
Any help gratefully accepted!
Thanks a lot,
Bob Cochran Greenbelt, Maryland
On Wed, 2005-01-19 at 22:25 -0500, Robert L Cochran wrote:
I compiled PHP version 5.0.3 from source obtained from php.net on a Pentium 4 system running Fedora Core 3 and this message appears in /var/log/messages after httpd starts:
audit(1106189173.206:0): avc: denied { execute } for pid=3999 path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file
Try running "restorecon /usr/lib/20041030/ldap.so". That should reset the type of the file to shlib_t. You'll notice that shared libraries directly in /usr/lib/ have this type; this ensures that protected daemons are not able to map other random files that may be in lib into executable memory.
(If that doesn't work, try "chcon -t shlib_t /usr/lib/20041030/ldap.so")
Colin Walters wrote:
On Wed, 2005-01-19 at 22:25 -0500, Robert L Cochran wrote:
I compiled PHP version 5.0.3 from source obtained from php.net on a Pentium 4 system running Fedora Core 3 and this message appears in /var/log/messages after httpd starts:
audit(1106189173.206:0): avc: denied { execute } for pid=3999 path=/usr/lib/20041030/ldap.so dev=dm-0 ino=3129353 scontext=user_u:system_r:httpd_t tcontext=root:object_r:lib_t tclass=file
Try running "restorecon /usr/lib/20041030/ldap.so". That should reset the type of the file to shlib_t. You'll notice that shared libraries directly in /usr/lib/ have this type; this ensures that protected daemons are not able to map other random files that may be in lib into executable memory.
(If that doesn't work, try "chcon -t shlib_t /usr/lib/20041030/ldap.so")
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Colin,
Thanks for your help! It worked for that specific file. Now I'm getting the same message for file "mysql.so" in the same directory, so I assume that I need to run 'restorecon' for every *.so file in that directory. (PHP created the directory and installed the modules to it.)
Thanks again!
Bob
On Wed, 2005-01-19 at 23:36 -0500, Robert L Cochran wrote:
Thanks for your help! It worked for that specific file. Now I'm getting the same message for file "mysql.so" in the same directory, so I assume that I need to run 'restorecon' for every *.so file in that directory. (PHP created the directory and installed the modules to it.)
Yeah; in general, software installation by third party installers is not a solved problem yet. "restorecon" can fix it for typical things such as shared libraries installed in /usr/lib or binaries in /usr/bin, but not for arbitrary paths such as an executable called /opt/mypackage/binaries/foo.
selinux@lists.fedoraproject.org