Bug 167098 - Something unclean about /etc/init.d/httpd
Something unclean about /etc/init.d/httpd
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-30 06:07 EDT by Jón Fairbairn
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-30 06:14:10 EDT
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 Jón Fairbairn 2005-08-30 06:07:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
/etc/init.d/httpd start
or "service httpd start"
produced different results from
(. /etc/init.d/httpd start)
or "bash /etc/init.d/httpd start"
In particular, executing the script with bash like that makes httpd work as I would expect from my configuration file.

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

How reproducible:
Always

Steps to Reproduce:
1. log in as root (as far as I recall, root's .bash* is unchanged from install)
2. start httpd 

[root@pictogramme ~]# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]

3. Check that home directories are accessible

[root@pictogramme ~]# wget --spider http://pictogramme/~jf/
--10:44:26--  http://pictogramme/%7Ejf/
           => `index.html'
Resolving pictogramme... 128.232.12.36
Connecting to pictogramme[128.232.12.36]:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
10:44:26 ERROR 403: Forbidden.

4. stop httpd

[root@pictogramme ~]# service httpd stop
Stopping httpd:                                            [  OK  ]

5. Start httpd by bashing the script

[root@pictogramme ~]# (. /etc/init.d/httpd start)
Starting httpd:                                            [  OK  ]

6. Check again that home directories can be accessed

[root@pictogramme ~]# wget --spider http://pictogramme/~jf/
--10:44:41--  http://pictogramme/%7Ejf/
           => `index.html'
Resolving pictogramme... 128.232.12.36
Connecting to pictogramme[128.232.12.36]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
200 OK



Expected Results:  I would expect (given that my httpd.conf allows it) that after
service httpd start 
home directories would be accessible (and that, unless I set relevant environment variables, bashing the script would have the same effect)

Additional info:

I've tried unsetting various variables in the environment, but every time the effect is the same: bashing the script makes it work. 

I originally tried "bash -x /etc/init.d/httpd start" to find out what was happening to make user dirs inaccessible, but that made it work!
Comment 1 Ignacio Vazquez-Abrams 2005-08-30 06:12:01 EDT
Smells like a SELinux issue. Does anything show up in /var/log/messages when you
try to access the files via HTTP and you get the 403?
Comment 2 Joe Orton 2005-08-30 06:14:10 EDT
Correct; with FC4, the SELinux policy is only applied to httpd when started via
the service script.

To ensure the homedirs are accessible under SELinux, ensure they are labelled
correctly; see http://fedora.redhat.com/docs/selinux-apache-fc3/sn-user-homedir.html

For further information on SELinux/Apache integration in Fedora Core,
please see: http://fedora.redhat.com/docs/selinux-apache-fc3/

For general information on SELinux in Fedora Core, please see:
http://fedora.redhat.com/docs/selinux-faq-fc3/
Comment 3 Jón Fairbairn 2005-08-30 06:32:58 EDT
OK, Nothing in /var/log/messages, but in /var/log/audit/audit.log

What's confusing is that I carefully avoided using the service script, using
/etc/init.d/httpd in both cases.

chcon -R -t httpd_sys_content_t public_html

seems to solve the problem.  It would be useful if httpd logged SELinux as the
reason for the denial

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