ID: 24604
Comment by: soenke at regelt dot com
Reported By: timo dot hummel at 4fb dot de
Status: Open
Bug Type: Documentation problem
Operating System: SuSE Linux 8.2 Linux 2.4.19
PHP Version: Irrelevant
New Comment:
safe_mode_gid should be a workaround for this.
@Developers: Please let us know your plans about this issue.
--
Soenke
Previous Comments:
------------------------------------------------------------------------
[2004-01-29 18:26:33] rlammers at angelfire dot com
The simplest way to let users do anything on my website is by creating
a subdir for them to separate their actions from others.
Now my webhost has turned safe_mode on and the only work-around is to
let the ftp-pasword lying around in a script file. Nice security that
is!.
Please fix this (imho major) bug. It makes no sense to let users create
a dir and not let them write to it.
------------------------------------------------------------------------
[2004-01-21 05:52:41] thorsten at rinne dot info
Hi,
using PHP as CGI with suPHP (www.suphp.org) there are no problems:
-rw-r--r-- 1 thorsten users 195 Jan 20 22:01 test.php
Then running test.php...
Result:
drwxr-xr-x 2 thorsten users 4096 Jan 20 22:03 test
-rw-r--r-- 1 thorsten users 195 Jan 20 22:01 test.php
It would be nice if this would work with mod_php!
bye
Thorsten
------------------------------------------------------------------------
[2003-12-28 06:32:42] s9608273 at student dot utwente dot nl
Dir 20031228122842 made with function mkdir() (uid/gid : 101:100)
This is the effect when moving uploaded file to this dir.
Warning: move_uploaded_file(): SAFE MODE Restriction in effect. The
script whose uid/gid is 507/507 is not allowed to access
/home/..../uploadedFiles/20031228122842 owned by uid/gid 101/100 in
...
Maybe all file operations can be performed as the user which owns the
script.
------------------------------------------------------------------------
[2003-11-11 23:36:49] ndhuyvu at yahoo dot com
drwxrwxrwx 2 32533 bcdt 4096 Oct 23 20:48 10
drwxrwxrwx 2 99 99 4096 Nov 11 22:25 19
drwxrwxrwx 2 99 99 4096 Nov 11 22:32 20
drwxrwxrwx 2 32533 bcdt 4096 Oct 23 20:47 4
drwxrwxrwx 2 32533 bcdt 4096 Nov 5 23:07 5
drwxrwxrwx 2 32533 bcdt 4096 Oct 23 20:47 6
drwxrwxrwx 2 32533 bcdt 4096 Oct 23 20:47 9
FTP LOGIN -> Create Dir -> is OK
drwxrwxrwx 2 32533 bcdt 4096 Oct 23 20:47 9
But :-(
When create Dir in php code
mkdir($datapath.$ID,0777);
or
chmod($datapath.$ID,0777);
mkdir($datapath.$ID,0777);
result:
drwxrwxrwx 2 99 99 4096 Nov 11 22:32 20
------------------------------------------------------------------------
[2003-11-06 12:22:40] timo dot hummel at 4fb dot de
>Use cgi-php.
>And no such problems at all.
Tell that 99% of all internet hosters. They just won't do it - for
certain reasons. And there will be problems - just read my bug report
again why this is not revelant to cgi-php.
>They _NEVER_ do this. Because to change user,
>process must be owned by
>root. It's mean no security.
Not necessarly. I suggested to change the safe mode logic, not the
creator to create directories.
>My opinion - not needed. Just read aboud mod_php.
>It's always run as apache user.
Yes, but again: Read my bug report carefully. Try it out yourself. If
you know about how unix and linux systems are setup, you'll quickly
discover why it fails. Also remember: Most providers provide PHP, but
only uploads via FTP. Thus, the user id's with which people upload
files don't match the user id of the webserver in most cases.
>File_uploads can working with 'chuid' script, for example.
Most providers also don't do this. What you are recommending here are
workarounds, but not solutions.
>Just turn safe_mode OFF and disable system, popen, >exec... functions
Again, Providers turn on SAFE_MODE because they think they make PHP
secure - but in fact, they are disabling file operations via the web
and 3rd party software (i.e. all scripts you can get on the web) pretty
useless.
Or to use plain words:
"Heck, I can create a directory but I cannot write to it afterwards?"
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/24604
--
Edit this bug report at http://bugs.php.net/?id=24604&edit=1
