Red Hat Bugzilla – Bug 168868
php passthru fails to execute command that works in shell
Last modified: 2007-11-30 17:07:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Description of problem:
I have legacy php code that worked fine on RHES3 and we upgraded to RHES4. Some of the legacy php code has failed to work with the php/apache/selinux on this version.
The main problem is with the php command passthru() (could likely be exec() and other related functions). Before the code worked well and after RHES4 it doesn't work anymore do to I believe is selinux policy.
I am quite new to selinux and I believe this may be a bug but can't rule out my misconfiguration or lack of knowledge how to make php work with selinux...
I also had the output png going to /var/www/html/tempdata/ instead of tmp but I was trying to isolate the problem first... it worked to save it to /var/www/html/tempdata before selinux...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. setup a php file as such in /var/www/html/
$cmd = "echo -e 'set term png color small; plot \"/tmp/tempdata/in.1234\" with lines 1' | gnuplot > /tmp/tempdata/410305.png";
$cmd_out = passthru($cmd);
add test data to /tmp/tempdata/in.1234
2. call the php program:
3. ls -adl /tmp/tempdata or with -Z for selinux policy
also more /var/log/httpd/error_log to see the file /tmp/tempdata/in.1234 was unable to be read due to permissions...
Actual Results: Command fails from php...
output of /var/log/httpd/error_log
gnuplot> set term png color small; plot "/tmp/tempdata/in.1234" with lines 1
can't read data file "/tmp/tempdata/in.1234"
line 0: util.c: Permission denied
[root@rainier1 tempdata]# ls -ald /tmp/tempdata/in.1234
-rw-r--r-- 1 apache apache 12 Sep 20 11:31 /tmp/tempdata/in.1234
[root@rainier1 tempdata]# ls -aldZ /tmp/tempdata/in.1234
-rw-r--r-- apache apache user_u:object_r:tmp_t /tmp/tempdata/in.1234
Expected Results: su to apache and run the same command from a sh and it works...
I guess it would fit under normal below but some functionality of passthru / exec is lost with no work around I know of...
Thanks... and hope this is not a 'known' issue I could not find.
Here is some more information and testing:
Permissions on tmp look normal from my read:
drwxrwxrwt 27 root root 4096 Sep 21 04:02 tmp
the directory inside tmp that I read is tempdata and it permissions are
drwxr-xr-x 2 apache apache 4096 Sep 21 10:54 /tmp/tempdata
(I chmod'ed it to 777 with no change in the behavior)
the selinux context is
drwxrwxrwx apache apache root:object_r:httpd_tmp_t /tmp/tempdata
for a normal tmp file is seems to be:
drwx------ root root root:object_r:tmp_t /tmp/misc_file
another test program...
echo passthru('ls -adl /tmp/*');
echo passthru('ls -adl /tmp/tempdata/*');
echo passthru("more /tmp/tempdata/in.147320b");
Here is the output trimmed for length...
drwx------ 3 root root 4096 Sep 11 21:34 /tmp/gconfd-root
drwx------ 2 root root 4096 Sep 11 23:50 /tmp/kde-root
drwx------ 2 root root 4096 Sep 11 21:34 /tmp/keyring-sTNHhu
drwx------ 2 root root 4096 Sep 6 23:43 /tmp/ssh-rGtsfE9688
drwx------ 2 root root 4096 Sep 10 09:46 /tmp/ssh-tRRCs23601
drwx------ 2 siri siri 4096 Sep 6 11:20 /tmp/ssh-wphDaC8647
========end of output========
the command passed through passthru in part 1 skips files as /tmp/tempdata doesn't show up. In
parts 2 and 3 it just does nothing.
A section of the /var/log/httpd/error_log is next...
From Part 1:
ls: /tmp/mapping-root: Permission denied
ls: /tmp/mapping-user1: Permission denied
ls: /tmp/mapping-user2: Permission denied
the above three are symbolic links and a deny may be normal
ls: /tmp/tempdata: Permission denied
ls: /tmp/tmp.xpi: Permission denied
ls: /tmp/xses-root.1gUSRD: Permission denied
Here are permissions and context for these last three errored parts
drwxrwxrwx apache apache root:object_r:httpd_tmp_t /tmp/tempdata
-rw-r--r-- root root root:object_r:tmp_t /tmp/tmp.xpi
-rw------- root root user_u:object_r:tmp_t /tmp/xses-root.1gUSRD
From Part 2:
ls: /tmp/tempdata/*: Permission denied
example of permissions and context (snipped)
ls -adlZ /tmp/tempdata/*
-rw-r--r-- apache apache root:object_r:httpd_tmp_t /tmp/tempdata/in.147320b
-rw-r--r-- apache apache root:object_r:httpd_tmp_t /tmp/tempdata/in.178348
-rw-r--r-- apache apache root:object_r:httpd_tmp_t /tmp/tempdata/in.223878
-rw-r--r-- apache apache root:object_r:httpd_tmp_t /tmp/tempdata/in.22513
From Part 3:
/tmp/tempdata/in.147320b: Permission denied
See ls for this file above...
Hope this helps...
Could you change the application back to writing to a directory other than tmp.
Then change the context on the directory to httpd_sys_script_rw_t, which should
allow apache to write to the directory.
I don't seem to be able to chcon to that context...
[root@inside www]# mkdir tempdata
[root@inside www]# chown apache:apache tempdata/
[root@inside www]# chcon httpd_sys_script_rw_t tempdata/
chcon: invalid context: httpd_sys_script_rw_t
Am I missing a switch? My RHES4 is completely 'up2date' so I don't think I am missing an update.
Here is the ls -adlZ on it
drwxr-xr-x apache apache root:object_r:httpd_sys_content_t tempdata
If this would work, it would certainly solve my problem. However, I thought it was a logical place to put
'throw-away' data and let the system clean it up. Do you know if this is this a behavior or a bug?
One additional comment... I just thought I would try the php passthru script with the httpd_sys_content_t
context and put the folder as above in the /var/www branch. The script now works. I will need to
explicitly take care of the generated data but that is workable.
I am still curious if this is a behavior or a bug and now why the httpd_sys_script_rw_t context is invalid,
and I am still happy to work on this if it is helpful for you folks.
chcon -t httpd_sys_script_rw_t
This is not a bug but a design feature. Basically we don't want apache or any
of its scripts reading/writing random places on the system. Especially not
/tmp, since this would be an avenue of attach against the users.
Ah... OK, I changed the folder to httpd_sys_script_rw_t and it appears to work as well as with the other
I presume httpd_sys_script_rw_t is better than httpd_sys_content_t or does it matter if it works?
Did I miss something in the php.net info or somethwere else which documents this? I am guessing
selinux/php specific information will be or is available somewhere to prempt these questions.
You can turn off the httpd_unified boolean to tighten up the security of apache,
by setting this context. (Of course you might have other problems.)