#42291 [Com]: Uploaded file permissions vary depending on file system configuration
ID: 42291 Comment by: mail at peter-thomassen dot de Reported By: rob-phpbugs at tigertech dot com Status: No Feedback Bug Type: Filesystem function related Operating System: Linux PHP Version: 5.2.4 New Comment: 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? Previous Comments: [2007-11-26 01:00:00] 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". [2007-11-18 23:47:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-11-05 23:28:25] 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-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()... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42291 -- Edit this bug report at http://bugs.php.net/?id=42291&edit=1
#39449 [Com]: Overloaded array properties do not work correctly
ID: 39449
Comment by: mail at peter-thomassen dot de
Reported By: pstradomski at gmail dot com
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.0
Assigned To: dmitry
New Comment:
I do agree with Denis in the sense that one should disable
the notice for read access (using foreach, p.ex.), until a
global solution including write access is found (or not).
This doesn't harm anyone and would save me some lines of
error_reporting() changes. Thanks!
Previous Comments:
[2006-12-06 11:08:10] brjann at gmail dot com
"// This should not raise notice
foreach( $a->overloaded_property as $val )
echo $val."\n";
// This should raise notice
$a->overloaded_property[] = 6;"
I do not agree with that. Neither of the examples should raise a
notice. There is no reason for
$a->overloadedprop = $bar
to work, but not
$a->overloadedprop[$foo] = $bar
or
foreach($a->overloadedprop){}
Either properties can be overloaded and therefore read, assigned and
iterated over, or not. Overloaded properties should behave the same way
as ordinary properties, or else the object's behaviour is
unpredictable.
Perhaps the solution of using __get() to return a reference is
unsatisfactory in some way, but the behaviour should still be there.
/Brjánn
[2006-12-04 08:55:15] denis at edistar dot com
I think the warning should be raised only when someone is
trying to write the overloaded property.
Foreach and other loop constructs are readonly constructs
except when they are using references of the overloaded
properties.
For example:
test;
}
}
$a = new A;
// This should not raise notice
foreach( $a->overloaded_property as $val )
echo $val."\n";
// This should raise notice
$a->overloaded_property[] = 6;
?>
Thank you,
Denis
[2006-11-19 11:53:11] v dot anagnostos at mail dot bg
Reproduce code:
---
test;
}
}
$a = new A;
foreach( $a->overloaded_property as $val )
echo $val."\n";
?>
Expected result:
1
2
3
4
5
Actual result:
--
Notice: Indirect modification of overloaded property
A::$overloaded_property has no effect in
C:\Apache\htdocs\dancho\index.php on line 15
1
2
3
4
5
[2006-11-14 20:31:16] cboden at gmail dot com
In the above example:
$a->arr[]='d';
produced the expected results in PHP-5.1 but now gives the following
error in PHP-5.2
"Notice: Indirect modification of overloaded property"
[2006-11-09 14:05:23] pstradomski at gmail dot com
Reopening.
This should never be "expected behaviour". This way encapsulation got
severly broken - __get was introduced to allow dynamic creation of
properties - and therefore implementation of record-like classes. Such
properties were meant to be indistinguishable from standard properties
- but aren't. Neither passing by reference works, nor array elements
do.
Developer can expect to be able to modify object properties for example
in such a way:
$x->arr = array('a');
array_push($x->arr, 'b');
Now it is impossible - although it should be. I understand previous
behaviour could be considered improper, bu now developers don't even
get a chance to choose between passing by value and passing by
reference.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39449
--
Edit this bug report at http://bugs.php.net/?id=39449&edit=1
