php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42291 Uploaded file permissions vary depending on file system configuration
Submitted: 2007-08-14 03:50 UTC Modified: 2007-11-26 01:00 UTC
Votes:45
Avg. Score:4.5 ± 0.8
Reproduced:41 of 42 (97.6%)
Same Version:18 (43.9%)
Same OS:36 (87.8%)
From: rob-phpbugs at tigertech dot com Assigned:
Status: No Feedback Package: Filesystem function related
PHP Version: 5.2.4 OS: Linux
Private report: No CVE-ID: None
 [2007-08-14 03:50 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-11-04 15:51 UTC] 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-11-04 17:16 UTC] 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-05 23:28 UTC] rob-phpbugs at tigertech dot com
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.
 [2007-11-26 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-06-10 15:48 UTC] mail at peter-thomassen dot de
I just checked this with today's snapshot (5.2.7 devel), and move_uploaded_file() now respects the umask setting.

For the temporary file (before the move_uploaded_file() call, usually in /tmp/), the umask setting is respected only for the owner's bits. Group and world permission are set to 0 (as if umask was 0x77, with x being the owner's umask). As I already said, everything is set right when moving the file away. It seems that this bug is fixed.

In production, I still have to use PHP 5.2.0 with some patches. Does anybody know in which version this bug was fixed?
 [2016-03-03 11:38 UTC] upadrian at gmail dot com
Same problem here on 5.5.31
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC