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): php-4.3.9-3.8 How reproducible: Always Steps to Reproduce: 1. setup a php file as such in /var/www/html/ php_test.php <? $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); echo $cmd; ?> add test data to /tmp/tempdata/in.1234 e.g., 1 2 3 4 5 2. call the php program: http://...../php_test.php 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... Additional info: 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... <?php echo '<pre>'; echo "1<br>"; echo passthru('ls -adl /tmp/*'); echo "2<br>"; echo passthru('ls -adl /tmp/tempdata/*'); echo "3<br>"; echo passthru("more /tmp/tempdata/in.147320b"); echo '</pre>'; ?> Here is the output trimmed for length... ========output======== 1 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 ....snip... 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 2 3 ========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... Dean W.
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? Thanks!
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. Dan
Ah... OK, I changed the folder to httpd_sys_script_rw_t and it appears to work as well as with the other context. 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. Thanks again!
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.)