Bug 133946 - httpd with modperl will not start
httpd with modperl will not start
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2004-09-28 12:16 EDT by Brian Millett
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:
Last Closed: 2004-10-18 16:13:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
trace from /var/log/messages (21.70 KB, text/plain)
2004-09-28 12:19 EDT, Brian Millett
no flags Details

  None (edit)
Description Brian Millett 2004-09-28 12:16:15 EDT
Description of problem: httpd will not start with selinux enabled

Version-Release number of selected component (if applicable):

How reproducible:
start httpd service

Steps to Reproduce:
1.service httpd start
Actual results:
Can't load a modperl module.

Expected results:
Should load the module

Additional info:
Comment 1 Brian Millett 2004-09-28 12:19:05 EDT
Created attachment 104445 [details]
trace from /var/log/messages

Trace from the /var/log/messages when I try to start httpd
Comment 2 Brian Millett 2004-09-28 12:24:20 EDT
Sorry for the many posts, but it seems that the submit process has
changed.  Or I'm just brain dead.

Here is the info about the modperl configuration:
The startup.pl (no big deal) NOTE that the perlmodule that fails is in
the /home/bpm/development/modperl directory.


use Apache2 ();
use lib qw(/home/bpm/development/modperl);

# enable if the mod_perl 1.0 compatibility is needed
#use Apache::compat ();

use ModPerl::Util ();           #for CORE::GLOBAL::exit

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();

use Apache::Request ();

use Apache::Server ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();

use APR::Table ();

use ModPerl::Registry ();
use CGI ();

use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';


From the perl.conf where I define the location:

PerlModule Employee
<Location /cgiApp>
	 SetHandler perl-script
     PerlResponseHandler Employee
     PerlSetEnv PERL_DL_NONLAZY 1

Now the error that happens when I start:
 service httpd start
Starting httpd: [Tue Sep 28 11:26:50 2004] [error] Can't locate
Employee.pm in @INC (@INC contains: /home/bpm/development/modperl
/usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl . /etc/httpd/ /etc/httpd/lib/perl) at (eval
6) line 3.\n[Tue Sep 28 11:26:50 2004] [error] Can't load Perl module
Employee for server indoffcallacctg.indoff.com:0, exiting...

Comment 3 Daniel Walsh 2004-09-28 14:33:39 EDT
A couple of thinkgs you might want to change.

The problem is that you are trying to run an executable in a users
home directory.  You can relabel the executable to work correctly via
a chcon call
chcon -R -t httpd_sys_script_exec_t /home/bpm/development/modperl

This should set the file context to allow http to run the executable.

Or you could move the modperl stuff to a system cgi-bin directory


You can run system-config-securitylevel and remove the transition to
httpd.  So apache will work without SELinux protection.  The
Comment 4 Brian Millett 2004-09-28 14:56:40 EDT
Ok, I was looking at the security permissions:
[bpm]$ ls -dalZ ~/development
drwxr-xr-x  bpm  bpm  system_u:object_r:user_home_t /home/bpm/development

Is it possible to have it relabeled to have both?
system_u:object_r:user_home_t:httpd_user_content_t  ??

With SELinux enabled, there seems to be a different mindset as to
containment of like processes.  Meaning, httpd stuff should be under
the apache root, etc.  It looks like things like CGI anywhere would
have problems, unless under the apache system location.  Is that
correct?   Also, what if I want to install apache, say in /opt ?  Do I
need to then change the paths in file_contexts?

I can edit and change the /var/www/cgi-bin/* files just fine as a
user.  The security perms are: user_u:object_r:httpd_sys_content_t
/var/www/cgi-bin/printenv.  Is it the user_u that allows that?

Thanks.  Sorry for the questions.
Comment 5 Brian Millett 2004-09-28 16:00:19 EDT
Ok, so I did chcon -R -t httpd_sys_script_exec_t
but then the app couldn't connect to the mysql database.

[Tue Sep 28 14:48:26 2004] [error] [client] DBI
connect('portal:localhost','bpm',...) failed: Can't connect to local
MySQL server through socket '/var/lib/mysql/mysql.sock' (13) at
/home/bpm/development/modperl/BPM/DBIPortalHandle.pm line 27\n

From the /var/log/messages 
Sep 28 14:30:46 indoffcallacctg kernel: audit(1096399846.362:0): avc:
 denied  { write } for  pid=5704 exe=/usr/sbin/httpd name=mysql.sock
dev=hda2 ino=620314 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:var_lib_t tclass=sock_file
Sep 28 14:48:26 indoffcallacctg kernel: audit(1096400906.879:0): avc:
 denied  { write } for  pid=5706 exe=/usr/sbin/httpd name=mysql.sock
dev=hda2 ino=620314 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:var_lib_t tclass=sock_file

So it looks like the sock was not setup to allow access. :-(

So the easy way out was to remove the transition to httpd.

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