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=42291&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42291&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42291&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42291&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42291&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42291&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=42291&r=needscript Try newer version: http://bugs.php.net/fix.php?id=42291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42291&r=support Expected behavior: http://bugs.php.net/fix.php?id=42291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42291&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42291&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42291&r=dst IIS Stability: http://bugs.php.net/fix.php?id=42291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42291&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=42291&r=mysqlcfg
