Hi guys.
Dunno if this is not new to you, but i am experiencing a strange behavior of the apache in FC4 with selinux enabled.
Ok. What have i done?
First i wrote some php stuff and was wondering why the Server did not allow to get some files in /css and does not allow to connect via an network socket to the postgresql server.
Then i restarted the Server with apachectl stop and apachectl start. From now on everything worked fine and like expected.
Then i did an Kernel update rebooted the machine and my Site was not reachable again. So i did some investigation and saw in the audit.log that selinux is disabling some stuff.
Then i restarted again with apachectl stop and start. And like expected the httpd started working again.
Is this an issue? I think this behavior is not normal :-)
On Wed, 2005-07-06 at 02:43 +0200, Stefan Held wrote:
Hi guys.
Dunno if this is not new to you, but i am experiencing a strange behavior of the apache in FC4 with selinux enabled.
Ok. What have i done?
First i wrote some php stuff and was wondering why the Server did not allow to get some files in /css and does not allow to connect via an network socket to the postgresql server.
Did you have a look at this guide?
http://fedora.redhat.com/docs/selinux-apache-fc3/
It needs to be updated for FC4, but should be helpful nonetheless.
Then i restarted the Server with apachectl stop and apachectl start. From now on everything worked fine and like expected.
The reason I believe is because apachectl restarts the Apache httpd daemon on its own. The way the Fedora targeted policy works for daemons is that they are only confined when executed via the /etc/init.d/* scripts, so when apachectl executes httpd it stays in unconfined_t.
This is to prevent issues such as the system administrator executing "httpd -t" and causing a domain transition to httpd_t which isn't allowed access to the administrator's terminal.
Probably we shouldn't ship the apachectl command in Fedora, instead requiring using "service httpd restart".
On Tue, Jul 05, 2005 at 10:47:15PM -0400, Colin Walters wrote:
On Wed, 2005-07-06 at 02:43 +0200, Stefan Held wrote:
Then i restarted the Server with apachectl stop and apachectl start. From now on everything worked fine and like expected.
The reason I believe is because apachectl restarts the Apache httpd daemon on its own. The way the Fedora targeted policy works for daemons is that they are only confined when executed via the /etc/init.d/* scripts, so when apachectl executes httpd it stays in unconfined_t.
Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway...
[root@tango ~]# service httpd stop Stopping httpd: [ OK ] [root@tango ~]# apachectl start [root@tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start
joe
On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote:
Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway...
[root@tango ~]# service httpd stop Stopping httpd: [ OK ] [root@tango ~]# apachectl start [root@tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start
On FC4, apachectl start leaves it running in unconfined_t. In FC3, since the system starts in unconfined_t (so both rc scripts and user shells are in the same domain), there is no distinction, so you wouldn't see a difference there.
On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote:
On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote:
Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway...
[root@tango ~]# service httpd stop Stopping httpd: [ OK ] [root@tango ~]# apachectl start [root@tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start
On FC4, apachectl start leaves it running in unconfined_t. In FC3, since the system starts in unconfined_t (so both rc scripts and user shells are in the same domain), there is no distinction, so you wouldn't see a difference there.
OK - can that be changed? I'd really much rather that apachectl, the init script, and direct invocation of /usr/sbin/httpd all had the same behaviour, as has been (mostly) the case forever.
joe
Joe Orton wrote:
On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote:
On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote:
Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway...
[root@tango ~]# service httpd stop Stopping httpd: [ OK ] [root@tango ~]# apachectl start [root@tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start
On FC4, apachectl start leaves it running in unconfined_t. In FC3, since the system starts in unconfined_t (so both rc scripts and user shells are in the same domain), there is no distinction, so you wouldn't see a difference there.
OK - can that be changed? I'd really much rather that apachectl, the init script, and direct invocation of /usr/sbin/httpd all had the same behaviour, as has been (mostly) the case forever.
joe
It already has been. apachectl is set to initrc_exec_t whith will start httpd in the correct context. Install the latest policy for FC4 and run restorecon on apachectl if it is not set to initrc_exec_t.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Fri, Jul 29, 2005 at 09:15:18AM -0400, Daniel J Walsh wrote:
It already has been. apachectl is set to initrc_exec_t whith will start httpd in the correct context. Install the latest policy for FC4 and run restorecon on apachectl if it is not set to initrc_exec_t.
Ah, great, yes, I see it on my current system. Thanks Dan.
joe
On Fri, 2005-07-29 at 11:39 +0100, Joe Orton wrote:
On Fri, Jul 08, 2005 at 09:43:30AM -0400, Stephen Smalley wrote:
On Fri, 2005-07-08 at 14:15 +0100, Joe Orton wrote:
Eh? I thought the transition happens upon exec of httpd regardless of who performs the exec. Empirical evidence suggests that's the case anyway...
[root@tango ~]# service httpd stop Stopping httpd: [ OK ] [root@tango ~]# apachectl start [root@tango ~]# ps axZ | grep httpd root:system_r:httpd_t 30536 ? Ss 0:00 /usr/sbin/httpd -k start
On FC4, apachectl start leaves it running in unconfined_t. In FC3, since the system starts in unconfined_t (so both rc scripts and user shells are in the same domain), there is no distinction, so you wouldn't see a difference there.
OK - can that be changed? I'd really much rather that apachectl, the init script, and direct invocation of /usr/sbin/httpd all had the same behaviour, as has been (mostly) the case forever.
For direct invocation of /usr/sbin/httpd; we can't have it both ways. It has to either be confined or not confined. People seem to want it unconfined so e.g. httpd -t can still print to the terminal.
Am Freitag, den 08.07.2005, 14:15 +0100 schrieb Joe Orton: [root@extranet ~]# service httpd restart httpd beenden: [ OK ] httpd starten: [ OK ]
[root@extranet ~]# ps auxZ | grep httpd root:system_r:httpd_t root 25934 2.9 0.4 19080 9252 ? Ss 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25936 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25937 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25938 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd root:system_r:httpd_t apache 25939 0.0 0.4 19212 9272 ? S 01:40 0:00 /usr/sbin/httpd
[root@extranet ~]# apachectl stop [root@extranet ~]# apachectl start [root@extranet ~]# ps auxZ | grep httpd root:system_r:unconfined_t root 25956 14.3 0.4 21160 9244 ? Ss 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25957 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25958 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start root:system_r:unconfined_t apache 25959 0.0 0.4 21292 9264 ? S 01:40 0:00 /usr/sbin/httpd -k start
selinux@lists.fedoraproject.org