Bug 498031 - php function move_uploaded_file ignores umask setting
php function move_uploaded_file ignores umask setting
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: php (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2009-04-28 11:17 EDT by info@kobaltwit.be
Modified: 2010-03-30 04:24 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 04:24:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix for the move_uploaded_file umask issue (974 bytes, patch)
2009-04-28 11:26 EDT, info@kobaltwit.be
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
PHP Bug Tracker 42291 None None None Never

  None (edit)
Description info@kobaltwit.be 2009-04-28 11:17:33 EDT
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:

Version-Release number of selected component (if applicable):

How reproducible:

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.
Comment 1 info@kobaltwit.be 2009-04-28 11:26:32 EDT
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.
Comment 2 Joe Orton 2009-10-13 09:51:26 EDT
Thanks for reporting and extracting the fix!
Comment 4 Joe Orton 2009-12-16 07:42:52 EST
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.


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.
Comment 8 errata-xmlrpc 2010-03-30 04:24:47 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.