Bug 168868 - php passthru fails to execute command that works in shell
php passthru fails to execute command that works in shell
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-20 15:05 EDT by Dean Waldow
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-22 14:24: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 Dean Waldow 2005-09-20 15:05:18 EDT
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.
Comment 1 Dean Waldow 2005-09-21 14:36:51 EDT
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.
Comment 2 Daniel Walsh 2005-09-22 10:10:23 EDT
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.
Comment 3 Dean Waldow 2005-09-22 11:00:14 EDT
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!
Comment 4 Dean Waldow 2005-09-22 11:11:14 EDT
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.
Comment 5 Daniel Walsh 2005-09-22 11:22:40 EDT
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
Comment 6 Dean Waldow 2005-09-22 11:36:00 EDT
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!
Comment 7 Daniel Walsh 2005-09-22 14:24:10 EDT
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.)


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