Use cgi-php.
And no such problems at all.

1.) Modify the SAFE_MODE concept to become consistent.
They _NEVER_ do this. Because to change user, process must be owned by root. It's mean no security.

2.) Modify the documentation of SAFE_MODE and all related file/directory
functions that for the proper operation of file and directory functions,
the owner and executor have to be the same user.

My opinion - not needed. Just read aboud mod_php. It's always run as apache user.

The above problems are one reason why most PHP content management systems recommend to turn SAFE_MODE off in order to make file uploads working.

File_uploads can working with 'chuid' script, for example.
Just turn safe_mode OFF and disable system, popen, exec... functions

>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?"

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

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.

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

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.

safe_mode_gid should be a workaround for this.

@Developers: Please let us know your plans about this issue.

--

Soenke

>It makes no sense to let users create
> a dir and not let them write to it.

Well, that's another thing. It's probably about the umask, however, most providers and/or distribution builders should take care of this, but aren't.

uhm thats not great

ftp doenst work , and CGI is not running, too :(

Warning: ftp_connect() [function.ftp-connect]: php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/www/htdocs/myhost.com/bla.php on line 382

@develop: plz upgrade SAFE_MODE : - )

This is a pretty old bug, so has this been fixed yet? My webhost is running a pretty darned old PHP version, but I don't see the point in bugging them to upgrade of this bug isn't fixed yet ..

Behavior of move_uploaded_file() with safe_mode is already described.

Functions affected by safe_mode have already a note about safe_mode.

safe_mode_gid is also already documented: "However, there may be environments where a strict UID check is not appropriate and a relaxed GID check is sufficient. This is supported by means of the safe_mode_gid switch. Setting it to On performs the relaxed GID checking, setting it to Off (the default) performs UID checking."

I suppose that the behavior of safe_mode is not going to change according proposal 1.

http://www.titov.net/safemodepatch/ - this patch should allow you to write to directories, created by PHP.

A workaround/solution to this problem on *nix

Assuming that httpd server runs as apache/apache (uid/gid), and php script is user/group. 

1) php.ini
safe_mode = On
safe_mode_gid = On

2) Create initial data directory, on install phase as:

mkdir /path/to/datadir
chown user.group /path/to/datadir
chmod 2777 /path/to/datadir

3) Create all subdirectories (within php), like:
mkdir(/path/to/datadir/subdir, 02777);

This way all subdirectry will inherit group from initial parent dir and SAFE_MODE won't complain, since all subdirs
and files will be apache.group.

IMPORTANT NOTE: After any subdirectory creation you shouldn't change directory permissions, otherwise it will loose
the GID bit and all files/subdirectories created afterwards won't have group inherited!