From: andrey at ruweb dot net
Operating system:
PHP version: 4.3.7
PHP Bug Type: Documentation problem
Bug description: safe_mode UID/GID checking works in other way than described
Description:
------------
Documentation said: "When safe_mode is on, PHP checks to see if the owner
of the current script matches the owner of the file to be operated on by a
file function"
THAT'S NOT TRUE! ;)
It seems PHP only checks to see if the owner of the current script matches
the owner of the DIRECTORY where located file to be operated.
So, if we have 2 files
script.php 644 user1:user1
passwd.txt 644 root:root
in directory
public_html/ 750 user1:apache
then script.php still able to readfile('passwd.txt'); without any
restrictions.
In most cases it doesn't important. But using option safe_mode_gid in such
way becomes almost useless because it can break security in some cases.
All we know that safe_mode+safe_mode_exec_dir is simple and effective way
to protect user files from other user's access.
At tht same time all we know that using safe_mode is very inconvinient
sometimes. Users can't create files from PHP in directories created by
PHP, etc. At the first look safe_mode_gid option is suitable to solve
those common safe_mode problems. But in fact it can be completely
insecure.
For example, we have a directory
/home/user01/public_html user01:apache 750
The permissions is 750 and uid/gid is user01:apache because it's the right
way to restrict access to user's files from other users.
And so, user01 have a file
/home/user01/public_html/config.php user01:user01 644
with some sensitive information.
Also, user02 have file
/home/user02/public_html/upload/script.php apache:apache 644
The uid/gid is 'apache' because that script was uploaded via PHP.
Now user02 is able to run script.php with
readfile('/home/user01/public_html/config.php'); inside, and PHP will not
restrict reading, just because GID of script.php is matches GID of
/home/user01/public_html/ directory. COMPLETELY REGARDLESS of config.php
ownership itself.
Why it's going such unexpected way?
Please change that or just make it clear in documentation.
--
Edit bug report at http://bugs.php.net/?id=29126&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29126&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29126&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29126&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29126&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29126&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29126&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29126&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29126&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29126&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29126&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29126&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29126&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29126&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29126&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29126&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29126&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29126&r=float
