#42291 [Opn]: Uploaded file permissions vary depending on file system configuration
ID: 42291 User updated by: rob-phpbugs at tigertech dot com Reported By: rob-phpbugs at tigertech dot com Status: Open Bug Type: Filesystem function related Operating System: Linux -PHP Version: 4.4.7 +PHP Version: 5.2.4 New Comment: I fear this bug could be ignored because I tagged it as happening on PHP 4. Just to make sure it's clear, I'm retagging it as happening in PHP 5.2.4 -- it affects all versions. Previous Comments: [2007-11-04 17:16:19] marcel dot wiechmann at gmail dot com Same problem here. But not only under php 4.4.7 also under php 5.2.4 [2007-11-04 15:51:26] chh at innov8 dot ch I can confirm this behaviour. If upload_tmp_dir is on the same filesystem as the destination folder (normally the webspace of the customer(s) then the file permissions are set to 0600 - otherwise 0644 (umask at 0022), when using move_uploaded_file(). The temp file - before calling move_uploaded_file() - also has 0600 permissions. This leads to a problem when using suphp (suexec, fastcgi or whatever) and upload-functions in php applications which do not set the permissions after using move_uploaded_file() [Joomla seems to be such a candidate - Typo3 does it right..]. If you upload a static file which should be readable by the webserver but isn't because only PHP (and other user running applications) can access the file. All Upload functions should use a chmod() after move_uploded_file()... [2007-08-14 03:50:47] rob-phpbugs at tigertech dot com Description: On all current PHP versions, move_uploaded_file() creates a destination file that is either mode 0600 or 0644 (on Linux, anyway), depending on whether move_uploaded_file() needed to copy the file across filesystems. If the file can be moved (renamed), then the resulting file is mode 0600, because the file was originally created with mkstemp. If the file needs to be copied, the resulting mode is 0644 instead (assuming a normal umask of 022). This behavior appears (to the script author who isn't familiar with how move_uploaded_file works internally) inconsistent and surprising, and is undocumented. Expected result: Permissions given to uploaded files should be consistent, depending only on the umask setting. In other words, if I pass move_uploaded_file() the same parameters with the same umask value, I would expect to see the same resulting permissions, regardless of whether PHP's temporary file location happens to be on the same file system as the final destination. One could argue that a script author should be aware of this behavior, and should therefore find out whether the temporary location is on the same file system and plan for the resulting behavior. However, that doesn't seem practical. First of all, the current behavior isn't documented, so few people are aware of it. Secondly, the file system that is used for temporary files may be out of the script author's control, and may change without his or her knowledge (especially in a shared hosting environment, etc.) This could have security implications: Uploaded files that used to be given mode 0600 and were therefore considered secure because the script author thought that's just how PHP works will suddenly start getting mode 0644 if the server admin moves /tmp to a dedicated partition, for example. Making the behavior consistent (one way or the other) would avoid confusion. If the behavior can't be made consistent, it would be good to document the current behavior so that authors know that relying on the mode is not safe. Actual result: -- Permissions are set to either 0600 or 0644 depending on filesystem configuration. -- Edit this bug report at http://bugs.php.net/?id=42291edit=1
#42291 [NEW]: Uploaded file permissions vary depending on file system configuration
From: rob-phpbugs at tigertech dot com Operating system: Linux PHP version: 4.4.7 PHP Bug Type: Filesystem function related Bug description: Uploaded file permissions vary depending on file system configuration Description: On all current PHP versions, move_uploaded_file() creates a destination file that is either mode 0600 or 0644 (on Linux, anyway), depending on whether move_uploaded_file() needed to copy the file across filesystems. If the file can be moved (renamed), then the resulting file is mode 0600, because the file was originally created with mkstemp. If the file needs to be copied, the resulting mode is 0644 instead (assuming a normal umask of 022). This behavior appears (to the script author who isn't familiar with how move_uploaded_file works internally) inconsistent and surprising, and is undocumented. Expected result: Permissions given to uploaded files should be consistent, depending only on the umask setting. In other words, if I pass move_uploaded_file() the same parameters with the same umask value, I would expect to see the same resulting permissions, regardless of whether PHP's temporary file location happens to be on the same file system as the final destination. One could argue that a script author should be aware of this behavior, and should therefore find out whether the temporary location is on the same file system and plan for the resulting behavior. However, that doesn't seem practical. First of all, the current behavior isn't documented, so few people are aware of it. Secondly, the file system that is used for temporary files may be out of the script author's control, and may change without his or her knowledge (especially in a shared hosting environment, etc.) This could have security implications: Uploaded files that used to be given mode 0600 and were therefore considered secure because the script author thought that's just how PHP works will suddenly start getting mode 0644 if the server admin moves /tmp to a dedicated partition, for example. Making the behavior consistent (one way or the other) would avoid confusion. If the behavior can't be made consistent, it would be good to document the current behavior so that authors know that relying on the mode is not safe. Actual result: -- Permissions are set to either 0600 or 0644 depending on filesystem configuration. -- Edit bug report at http://bugs.php.net/?id=42291edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42291r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42291r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42291r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42291r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42291r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42291r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42291r=needscript Try newer version:http://bugs.php.net/fix.php?id=42291r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42291r=support Expected behavior:http://bugs.php.net/fix.php?id=42291r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42291r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42291r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42291r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42291r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42291r=dst IIS Stability:http://bugs.php.net/fix.php?id=42291r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42291r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42291r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42291r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42291r=mysqlcfg
#15259 [Com]: PHP fails if RLimitMEM directive is used
ID: 15259 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: RedHat Linux 7.2 PHP Version: 4.1.x New Comment: Since upgrading to the RedHat standard php-4.1.2-7.2.6 RPM version, I have found a much simpler test case demonstrating the problem. From the command line: - $ php -v 4.1.2 $ ulimit -v 3 $ php -v Content-type: text/html PHP Fatal error: Unable to start session mm module in Unknown on line 0 - This shows that PHP doesn't work properly when the memory RLIMIT is ~30 MB. This is a problem for people who use PHP in CGI mode in hosting environments with memory limits. Again, this is related to the use of --with-mm when compiling. If PHP is compiled *without* the --with-mm line, the problem does not occur. Hope this helps. Previous Comments: [2002-05-01 14:07:04] [EMAIL PROTECTED] I have done some more investigation and found that the problem only occurs when PHP is compiled --with-mm (which is the Red Hat default). If PHP is compiled without mm support, the problem does not happen (which is an acceptable workaround for me, and which should be useful for others who experience this problem). I still do not quite understand why the original problem happens, though. I suspect that PHP is using mm to allocate a large chunk of shared memory (perhaps around 32 MB?), and that allocation somehow fails in a silent manner. Then PHP tries to use that memory to read the POSTed data on STDIN, which fails. When this problem happens, I don't receive a premature end of script headers message or anything like that. PHP seems to work normally (in my limited testing) -- it is simply unable to see the POSTed data from the form. It acts as though the POSTed data was never sent (data sent by method GET works properly). I suspect if I tried some more extensive testing, I'd find that other parts of PHP that rely on mm memory allocation would fail under these circumstances, too (but I don't know what those are to be able to test specifics). Anyway, I've found my workaround and am happy, but it does seem that something in the mm code isn't quite right to cause silent failures. It's possible that this problem (apparent silent failure when memory can't be allocated by mm) might also occur in other low-memory situations, too, and that the artificially imposed RLimit limitation perhaps just makes it extremely visible and repeatable. If it helps others to test, this problem is easily duplicated by: 1. Set up Apache with the directive RLimitMEM 2000 (for example -- anything above 10 MB and below 40 MB shows the problem on my machine). 2. Compile PHP as a CGI --with-mm (I'm also using the rest of the default build options from the Red Hat 7.2 package; I suppose it's theoretically possible that those are affecting it, too -- if you can't duplicate, use the full-blown Red Hat build options). 3. Create a trivial test page that uses method POST to send data to any PHP script. 4. The PHP script will incorrectly act as if no parameters were POSTed. 5. Recompile PHP without the --with-mm line and the problem goes away. Hope this is useful. [2002-05-01 06:14:57] [EMAIL PROTECTED] Please research about the error message premature end of script headers also. It seems this could be Change Request. [2002-05-01 03:19:16] [EMAIL PROTECTED] I don't think this should be classified as a bogus bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be able to LIMIT the
Bug #15259 Updated: PHP fails if RLimitMEM directive is used
ID: 15259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: RedHat Linux 7.2 PHP Version: 4.0.6 New Comment: I don't think this should be classified as a bogus bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. Previous Comments: [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be able to LIMIT the resources on Memory for other things (Perl, FrontPage, and other cgi programs) [2002-01-28 17:56:48] [EMAIL PROTECTED] This cannot be implemented. Use PHP memory limit. [2002-01-28 14:45:33] [EMAIL PROTECTED] I have php compiled as cgi and calling the php binary from apache via AddHandler. I have thousands of users on this box and I have RLimitMEM directives. Using 4.0.6 and 4.1.1 I noticed if I have RLimitMEM defined, having a form POST to the php binary, i get : premature end of script headers. If I remark out the RLimitMEM entry in the VirtualHost directive, all is good? Any work arounds? -- Edit this bug report at http://bugs.php.net/?id=15259edit=1
Bug #15259 Updated: PHP fails if RLimitMEM directive is used
ID: 15259 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: RedHat Linux 7.2 PHP Version: 4.1.x New Comment: I have done some more investigation and found that the problem only occurs when PHP is compiled --with-mm (which is the Red Hat default). If PHP is compiled without mm support, the problem does not happen (which is an acceptable workaround for me, and which should be useful for others who experience this problem). I still do not quite understand why the original problem happens, though. I suspect that PHP is using mm to allocate a large chunk of shared memory (perhaps around 32 MB?), and that allocation somehow fails in a silent manner. Then PHP tries to use that memory to read the POSTed data on STDIN, which fails. When this problem happens, I don't receive a premature end of script headers message or anything like that. PHP seems to work normally (in my limited testing) -- it is simply unable to see the POSTed data from the form. It acts as though the POSTed data was never sent (data sent by method GET works properly). I suspect if I tried some more extensive testing, I'd find that other parts of PHP that rely on mm memory allocation would fail under these circumstances, too (but I don't know what those are to be able to test specifics). Anyway, I've found my workaround and am happy, but it does seem that something in the mm code isn't quite right to cause silent failures. It's possible that this problem (apparent silent failure when memory can't be allocated by mm) might also occur in other low-memory situations, too, and that the artificially imposed RLimit limitation perhaps just makes it extremely visible and repeatable. If it helps others to test, this problem is easily duplicated by: 1. Set up Apache with the directive RLimitMEM 2000 (for example -- anything above 10 MB and below 40 MB shows the problem on my machine). 2. Compile PHP as a CGI --with-mm (I'm also using the rest of the default build options from the Red Hat 7.2 package; I suppose it's theoretically possible that those are affecting it, too -- if you can't duplicate, use the full-blown Red Hat build options). 3. Create a trivial test page that uses method POST to send data to any PHP script. 4. The PHP script will incorrectly act as if no parameters were POSTed. 5. Recompile PHP without the --with-mm line and the problem goes away. Hope this is useful. Previous Comments: [2002-05-01 06:14:57] [EMAIL PROTECTED] Please research about the error message premature end of script headers also. It seems this could be Change Request. [2002-05-01 03:19:16] [EMAIL PROTECTED] I don't think this should be classified as a bogus bug. I ran into the same issue when using resource limits in cgiwrap, sbox, and a custom version of suexec that calls setrlimit(RLIMIT_AS, ...). For some reason I can't determine, PHP refuses to parse POSTed CGI parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on my machine), despite the fact that PHP itself never uses more than about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with no trouble. Perl CGI scripts do not have the same problem. As with the previous poster, using PHP's built-in memory limit is not an option for me -- I'm allowing customers to run their own PHP scripts on shared servers, and the memory limit must be enforced at the OS level to prevent users from running system calls, etc., that exceed the limit. This issue is unfortunately preventing me from offering PHP to several thousand customers. I hope that this bug can be reopened and fixed. I have spent several hours trying to figure out the cause of it in the hope that I could send a patch, but alas, I can't see where the problem is. [2002-01-28 18:22:49] [EMAIL PROTECTED] I can't just use PHP Limit.. I need to be able to LIMIT the resources on Memory for other things (Perl, FrontPage, and other cgi programs) [2002-01-28 17:56:48] [EMAIL PROTECTED] This cannot be implemented. Use PHP memory limit. [2002-01-28 14:45:33] [EMAIL PROTECTED] I have php compiled as cgi and calling the php binary from apache via AddHandler. I have thousands of users on this box and I have RLimitMEM directives. Using 4.0.6 and 4.1.1 I noticed if I have RLimitMEM defined, having a form POST to the php binary, i get : premature end of script headers. If I remark out the RLimitMEM entry in the VirtualHost directive, all is good? Any work arounds?
