Description of problem: The php function move_uploaded_file generates inconsistent destination file permissions, depending on how the file is moved: if the source and destination path are on the same filesystem, the file is moved. If the paths are on different filesystems, the file is copied. Note, this is a php internal decision, not something a user can influence in any way. If the file is moved, the destination file will always have 0600 as permissions. If it's copied, the destination file's permissions will be determined by the active umask (default 0022, so default file permissions are 0644). The proper behaviour would be that the destination file's permissions are always determined by the active umask. This bug is mostly apparent in shared hosting environments running a php based webapplication. Examples of affected applications are drupal and joomla. These applications use php to upload a file that should later be accessed by the httpd server. Due to the 0600 permissions, this won't always work. For more details, see the original bugreport on the php bugtracker: http://bugs.php.net/bug.php?id=42291 Version-Release number of selected component (if applicable): 5.1.6 How reproducible: Always Steps to Reproduce: 1. Install one of the affected webapplications on a webserver 2. Use the application to upload a file 3. Login to the server, and observe that the uploaded file has got 0600 file permissions even though the umask would allow more liberal permissions. (Of course, only if the upload tmp dir is on the same file system than the final destination) Actual results: Depending on the rest of the setup, this file will not be accessible by httpd. Expected results: The permissions of the uploaded file should obey the umask. Additional info: php developers have acknowleged this bug and fixed it in a later release of php. The original bugreport indicates that this was fixed in at least 5.2.7.
Created attachment 341588 [details] Fix for the move_uploaded_file umask issue I have dug in the php cvs repository and found that this issue was fixed in cvs in ext/standard/basic_functions.c, revision 1.818. I have taken the changes there and reworked them to be compatible with redhat's version of php 5.1.6. The attached patch should fix the problem for RHEL5.3.
Thanks for reporting and extracting the fix!
I've made test packages available which should fix this issue. These packages are unsupported, have not been through the standard Red Hat QA process, and are not recommended for use on production systems. http://people.redhat.com/~jorton/Tikanga-php/ Use of these packages may prevent you from (automatically) upgrading to any asynchronous security errata which are issued before the release of RHEL 5.5 due to version mismatches. Please record any feedback on use of these test packages (positive or negative!) on this bug report.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0241.html