#36467 [NEW]: odd safe_mode restriction and possible security concern

From: mike at silverservers dot com Operating system: CentOS 4.2 PHP version: 4.4.2 PHP Bug Type: Safe Mode/open_basedir Bug description: odd safe_mode restriction and possible security concern Description: ------------ I believe this is a bug in safe_mode. I have posted this to newsgroups but no one would touch it. Scenario: safe_mode On safe_mode_gid = On safe_mode_include_dir = /usr/local/custom/phpincludes/ safe_mode_exec_dir = /usr/local/custom/phpexec/ Notes: 1) phpexec contains .php scripts that are being access through an apache "alias": Alias /CustomScripts "/usr/local/custom/phpexec/" 2) for the example, all files in phpexec and phpincludes are owned by root (0) 3) there are multiple apache process running under different UID's, for example, as user1:user1 (502:502), as user2:user2 (505:505) etc. Situation: If a visitor to the website accesses the PHP script via http://www.domainname.com/CustomScripts/script.php - even though the permissions of the script are 755 (IE, world executable), the script is NOT run as the user that calls the script (ie UID 502). The script is run as the linux file "owner" which is root (UID 0). For whatever reason this may be desired, but the problem is, that "script.php" is supposed to access files owned by user1 (UID 502) -- however safe_modedoes NOT allow script.php (UID 0) to access files owned by user1 (UID 502). To me, this seems ridiculous. The reason the executables are even placed in the /usr/local/custom/phpexec directory is to allow all apache processes on the server to run the same scripts, without having to install them individually in every instance. They are owned by a non-webserver user to prevent them from being modified via the web. Now, since they are being forcibly executed as the non-web user, they cannot access the actual webusers content. It's like borrowing your neighbors lawnmower, but for some reason, it won't cut your lawn. It will let you cut his lawn. It will let him cut his lawn, but for some unknown reason, it won't work when you try to use his lawnmower to cut your own lawn. QUESTION: Aside from some possible security concerns that come up with this behavior, does this also qualify as a bug? -- Edit bug report at http://bugs.php.net/?id=36467&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36467&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36467&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36467&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36467&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36467&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36467&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=36467&r=needscript Try newer version: http://bugs.php.net/fix.php?id=36467&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36467&r=support Expected behavior: http://bugs.php.net/fix.php?id=36467&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36467&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36467&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36467&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36467&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36467&r=dst IIS Stability: http://bugs.php.net/fix.php?id=36467&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36467&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36467&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36467&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=36467&r=mysqlcfg