php-general Digest 23 Sep 2013 18:36:21 -0000 Issue 8374
Topics (messages 322149 through 322159):
Re: filesize() fails on file and works on it's copy (same permissions, same
directory)
322149 by: Negin Nickparsa
322150 by: Carsten Jensen
322158 by: Tamara Temple
Re: Apache
322151 by: Domain nikha.org
322152 by: Tim Streater
322153 by: Stuart Dallas
322159 by: Domain nikha.org
Re: Friday's Question
322154 by: Eric K. Dickinson
Problem with mbstring.internal_encoding, mcrypt and php-fpm
322155 by: Condor
322156 by: Aziz Saleh
322157 by: Condor
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
regardless of you, saying they have same permissions I think they do not
have the same permission
try to use --reference for chmod to see if there is any differences
try to copy the file keeping the whole permissions from original using sudo
cp -rp and check.
if this copy has the warning then your problem is from the permissions.
Sincerely
Negin Nickparsa
On Tue, Aug 13, 2013 at 11:30 AM, Michał Kochanowicz
<mic...@michal.waw.pl>wrote:
> Hello
>
> I've got a file, which can't be checked with filesize(). I copy it (with
> permissions) and then I can filesize() the copy. This is same directory,
> permissions are same. I don't understand what's the difference. Can you
> help me?
>
> Original file:
> File: 'DSC_5196_fx-1553725666.JPG'
> Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
> Device: 803h/2051d Inode: 5905591363 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
> Access: 2013-08-13 00:47:28.107477918 +0200
> Modify: 2013-08-12 21:38:27.219913208 +0200
> Change: 2013-08-13 00:47:08.931478654 +0200
> Birth: -
>
> Copy:
> File: 'DSC_5196_fx-1553725666_X.JPG'
> Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
> Device: 803h/2051d Inode: 144 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
> Access: 2013-08-13 00:45:48.000000000 +0200
> Modify: 2013-08-12 21:38:27.000000000 +0200
> Change: 2013-08-13 00:47:28.199477914 +0200
> Birth: -
>
> The only difference is inode: (5905591363 - doesn't work vs 144 - does
> work).
>
> Test script:
>
> <html>
> <body>
> <pre>
> <?
> $f3 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
> DSC_5196_fx-1553725666.JPG';
> $f4 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
> DSC_5196_fx-1553725666_X.JPG';
>
> print $f3.": ".filesize($f3)."\n";
> print $f4.": ".filesize($f4)."\n";
>
> ?>
> </pre>
> </body>
> </html>
>
> Result:
>
> Warning: filesize(): stat failed for /home/services/httpd/html.**
> galeria.XXX/gallery/var/**albums/988_Rok-2013/333_**
> Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG in
> /home/services/httpd/html.**galeria.michal.waw.pl/**
> gallery3-3.0.x/test.php<http://html.galeria.michal.waw.pl/gallery3-3.0.x/test.php>on
> line 13
> /home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG:
>
> /home/services/httpd/html.**galeria.XXX/gallery/var/**
> albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666_X.JPG:
> 1907383
>
> Regards
> Michał
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
if you have console access and the cli version of php works,
what does
echo filesize('/path/to/file');
tell (try running as root, then later as uid 51/webuser)
this will eliminate permission doubts
also you should use <?php as start tag instead of only <?
cheers
Carsten
On 09/23/2013 10:06 AM, Negin Nickparsa wrote:
regardless of you, saying they have same permissions I think they do not
have the same permission
try to use --reference for chmod to see if there is any differences
try to copy the file keeping the whole permissions from original using sudo
cp -rp and check.
if this copy has the warning then your problem is from the permissions.
Sincerely
Negin Nickparsa
On Tue, Aug 13, 2013 at 11:30 AM, Michał Kochanowicz
<mic...@michal.waw.pl>wrote:
Hello
I've got a file, which can't be checked with filesize(). I copy it (with
permissions) and then I can filesize() the copy. This is same directory,
permissions are same. I don't understand what's the difference. Can you
help me?
Original file:
File: 'DSC_5196_fx-1553725666.JPG'
Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
Device: 803h/2051d Inode: 5905591363 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
Access: 2013-08-13 00:47:28.107477918 +0200
Modify: 2013-08-12 21:38:27.219913208 +0200
Change: 2013-08-13 00:47:08.931478654 +0200
Birth: -
Copy:
File: 'DSC_5196_fx-1553725666_X.JPG'
Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
Device: 803h/2051d Inode: 144 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
Access: 2013-08-13 00:45:48.000000000 +0200
Modify: 2013-08-12 21:38:27.000000000 +0200
Change: 2013-08-13 00:47:28.199477914 +0200
Birth: -
The only difference is inode: (5905591363 - doesn't work vs 144 - does
work).
Test script:
<html>
<body>
<pre>
<?
$f3 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
DSC_5196_fx-1553725666.JPG';
$f4 = '/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**
DSC_5196_fx-1553725666_X.JPG';
print $f3.": ".filesize($f3)."\n";
print $f4.": ".filesize($f4)."\n";
?>
</pre>
</body>
</html>
Result:
Warning: filesize(): stat failed for /home/services/httpd/html.**
galeria.XXX/gallery/var/**albums/988_Rok-2013/333_**
Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG in
/home/services/httpd/html.**galeria.michal.waw.pl/**
gallery3-3.0.x/test.php<http://html.galeria.michal.waw.pl/gallery3-3.0.x/test.php>on
line 13
/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666.JPG:
/home/services/httpd/html.**galeria.XXX/gallery/var/**
albums/988_Rok-2013/333_**Rydzewo-04-06.08.2013/Sobota/**DSC_5196_fx-1553725666_X.JPG:
1907383
Regards
Michał
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Aug 13, 2013, at 3:00 AM, Michał Kochanowicz <mic...@michal.waw.pl> wrote:
> Hello
>
> I've got a file, which can't be checked with filesize(). I copy it (with
> permissions) and then I can filesize() the copy. This is same directory,
> permissions are same. I don't understand what's the difference. Can you help
> me?
>
> Original file:
> File: 'DSC_5196_fx-1553725666.JPG'
> Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
> Device: 803h/2051d Inode: 5905591363 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
> Access: 2013-08-13 00:47:28.107477918 +0200
> Modify: 2013-08-12 21:38:27.219913208 +0200
> Change: 2013-08-13 00:47:08.931478654 +0200
> Birth: -
>
> Copy:
> File: 'DSC_5196_fx-1553725666_X.JPG'
> Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
> Device: 803h/2051d Inode: 144 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 51/ http) Gid: ( 51/ http)
> Access: 2013-08-13 00:45:48.000000000 +0200
> Modify: 2013-08-12 21:38:27.000000000 +0200
> Change: 2013-08-13 00:47:28.199477914 +0200
> Birth: -
>
> The only difference is inode: (5905591363 - doesn't work vs 144 - does work).
>
> Test script:
>
> <html>
> <body>
> <pre>
> <?
> $f3 =
> '/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG';
> $f4 =
> '/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666_X.JPG';
>
> print $f3.": ".filesize($f3)."\n";
> print $f4.": ".filesize($f4)."\n";
>
> ?>
> </pre>
> </body>
> </html>
>
> Result:
>
> Warning: filesize(): stat failed for
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG
> in /home/services/httpd/html.galeria.michal.waw.pl/gallery3-3.0.x/test.php
> on line 13
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG:
>
> /home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666_X.JPG:
> 1907383
>
> Regards
> Michał
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
That is one whopping-big inode number — I am really out on a limb here, but is
this a 32-bit vs 64-bit issue?
--- End Message ---
--- Begin Message ---
Tamara Temple am Montag, 23. September 2013 - 06:49:
>
> GoDaddy's default plesk-generated configuration for FastCGI-served PHP
files only looked to see if the file contained ".php" somewhere on it's
path - i.e. it would happily execute 'malicilous.php.txt' as php code,
even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
>
Yes, looks stupid.
But my service prodider wrote me this, I quote:
---QUOTE---
This is because Apache offers features like language negotiation based
on extensions, too -- the final extension doesn't always just specify
the handler; it can specify other things. Apache can automatically pick
a German-language script from these, for example:
file.php.de
file.php.en
Whether this is a good idea or not is debatable. It's possible to set
things up in a different way (using FilesMatch instead of AddHandler)
to
avoid this particular problem, but that breaks other things, so there's
no perfect solution.
More generally, the real problem is that scripts are looking at the
final extension of uploaded files to decide whether they're safe or
not,
which is dangerous. They're simply assuming that a ".gif" file can't
run
a PHP interpreter, for example... which is usually true, but certainly
not always: some people run all their files through PHP.
---END QUOTE---
The problem is the weak PHP upload mechanism!
As workaround my service provider tries to block suspicious filenames,
but the PHP developpers themself should work on this severe security
problem.
Niklaus
--- End Message ---
--- Begin Message ---
On 23 Sep 2013 at 11:37, Domain nikha.org <m...@nikha.org> wrote:
> The problem is the weak PHP upload mechanism!
I'd have said the problem is weak metadata provision - overloading the filename
for other purposes.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
On 23 Sep 2013, at 11:37, Domain nikha.org <m...@nikha.org> wrote:
> Tamara Temple am Montag, 23. September 2013 - 06:49:
>>
>> GoDaddy's default plesk-generated configuration for FastCGI-served PHP
> files only looked to see if the file contained ".php" somewhere on it's
> path - i.e. it would happily execute 'malicilous.php.txt' as php code,
> even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
>>
>
> Yes, looks stupid.
> But my service prodider wrote me this, I quote:
> ---QUOTE---
> This is because Apache offers features like language negotiation based
> on extensions, too -- the final extension doesn't always just specify
> the handler; it can specify other things. Apache can automatically pick
> a German-language script from these, for example:
>
> file.php.de
> file.php.en
>
> Whether this is a good idea or not is debatable. It's possible to set
> things up in a different way (using FilesMatch instead of AddHandler)
> to
> avoid this particular problem, but that breaks other things, so there's
> no perfect solution.
>
> More generally, the real problem is that scripts are looking at the
> final extension of uploaded files to decide whether they're safe or
> not,
> which is dangerous. They're simply assuming that a ".gif" file can't
> run
> a PHP interpreter, for example... which is usually true, but certainly
> not always: some people run all their files through PHP.
> ---END QUOTE---
This is somewhat daft. Yes, Apache offers this feature, but you don't need to
configure it to work will all extensions. I'd be curious to know what their
issue is with using FilesMatch, since that provides a way to disable this
behaviour. And, honestly, who would have a PHP file per language? I think it's
perfectly reasonable to not allow that, because duplicating PHP code across
many files is an incredible stupid way to support multiple languages.
"Some people run all their files through PHP" - true, but that doesn't mean
they should, or that you, as a responsible web host, should be endorsing it.
> The problem is the weak PHP upload mechanism!
> As workaround my service provider tries to block suspicious filenames,
> but the PHP developpers themself should work on this severe security
> problem.
PHP developers should absolutely validate all content coming in from users in
every possible way, but I would be highly dubious about trusting a host who
gives the reason above for what I consider a lax and insecure Apache
configuration. It's like saying they sliced your arm off with their chainsaw
because it's made for cutting things, attempting to dodge all responsibility
for having swung it in your direction!
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Stuart Dallas am Montag, 23. September 2013 - 12:58:
> And, honestly, who would have a PHP file per language? I think it's
perfectly reasonable to not allow that, because duplicating PHP code
across many files is an incredible stupid way to support multiple
languages.
>
I agree!! Didn't even know, that this kind of faked language support
exists...
> "Some people run all their files through PHP" - true, but that doesn't
mean they should, or that you, as a responsible web host, should be
endorsing it.
>
> PHP developers should absolutely validate all content coming in from
users in every possible way, but I would be highly dubious about
trusting a host who gives the reason above for what I consider a lax and
insecure Apache configuration. It's like saying they sliced your arm off
with their chainsaw because it's made for cutting things, attempting to
dodge all responsibility for having swung it in your direction!
>
OK, in principle, I also agree. But this case is very easy to handle.
I'm simply running "str_replace()" against dangerous parts of uploaded
filenames, ".php" for instance. After that, Apache in every
configuration will just serve, and never execute user uploaded files.
Remains the risk on the clients side, I must concede. Better solutions?
Nice days,
Niklaus
--- End Message ---
--- Begin Message ---
54, Only when the surface of the desk is problematic.
On 09/20/2013 12:58 PM, Larry Martell wrote:
On Fri, Sep 20, 2013 at 10:51 AM, Tedd Sperling <t...@sperling.com> wrote:
Hi gang:
Do you use a Mousepad?
My reason for asking is that I've used a Mousepad ever since mice first came
out (back when they had one ball).
Now that mice are optical (no balls), Mousepads are not really needed -- or so
I'll told by the college -- you see, they don't provide Mousepads for their
student's computers.
As such, I wondered what's the percentage of programmers still using a Mousepad?
Secondly, are Mousepads used primarily by older programmers (like me) while
younger programmers don't use Mousepads, or what?
So -- please respond with:
Age: *
Mousepad: Yes/No
54 Yes
--- End Message ---
--- Begin Message ---
Hello,
from two days I have strange problem with this param
mbstring.internal_encoding on nginx and php-fpm.
I use php version 5.4.20 and when I setting mbstring.internal_encoding I
have a problem with mcrypt.
NOTICE: PHP message: PHP Warning: mcrypt_generic_init(): Iv size
incorrect; supplied length: 12, needed: 8 in file.php
I setup php.ini file:
zend.multibyte = On
default_mimetype = "text/html"
default_charset = "UTF-8"
mbstring.internal_encoding = UTF-8
and here is function:
85 private function decrypt($blob)
86 {
87 $deckey = $_SESSION['key'];
88 $realkey = sha1($deckey, true);
89 $rawblob = hex2bin($blob); /* binary blob */
90 $td = mcrypt_module_open($this->CIPHER, "",
MCRYPT_MODE_CFB, "");
91 $iv = mb_substr($rawblob, 0,
mcrypt_enc_get_iv_size($td)); /* IV */
92 if (mb_strlen($iv) < mcrypt_enc_get_iv_size($td))
return FALSE;
93 $ct = mb_substr($rawblob,
mcrypt_enc_get_iv_size($td)); /* CipherText */
94 ---> mcrypt_generic_init($td, $realkey, $iv);
95 $unblob = mdecrypt_generic($td, $ct);
96 mcrypt_generic_deinit($td);
97 $pt = mb_substr($unblob, 20);
98 $check = mb_substr($unblob, 0, 20);
99 if ($check != sha1($pt, true))
100 {
101 return FALSE;
102 } else {
103 return $pt;
104 }
105 }
The same code with the same config options is worked fine with apache
httpd.
Any one can give me a little help ?
Thanks
Regards,
Hristo S.
--- End Message ---
--- Begin Message ---
Hristo,
Try changing the php.ini config:
mbstring.func_overload 0
See if that helps your issue, more on what it does:
http://php.net/manual/en/mbstring.overload.php
Aziz
On Mon, Sep 23, 2013 at 8:23 AM, Condor <con...@stz-bg.com> wrote:
>
> Hello,
>
> from two days I have strange problem with this param
> mbstring.internal_encoding on nginx and php-fpm.
> I use php version 5.4.20 and when I setting mbstring.internal_encoding I
> have a problem with mcrypt.
>
> NOTICE: PHP message: PHP Warning: mcrypt_generic_init(): Iv size
> incorrect; supplied length: 12, needed: 8 in file.php
>
> I setup php.ini file:
>
> zend.multibyte = On
> default_mimetype = "text/html"
> default_charset = "UTF-8"
> mbstring.internal_encoding = UTF-8
>
>
>
> and here is function:
>
> 85 private function decrypt($blob)
> 86 {
> 87 $deckey = $_SESSION['key'];
> 88 $realkey = sha1($deckey, true);
> 89 $rawblob = hex2bin($blob); /* binary blob */
> 90 $td = mcrypt_module_open($this->**CIPHER, "",
> MCRYPT_MODE_CFB, "");
> 91 $iv = mb_substr($rawblob, 0,
> mcrypt_enc_get_iv_size($td)); /* IV */
> 92 if (mb_strlen($iv) < mcrypt_enc_get_iv_size($td))
> return FALSE;
> 93 $ct = mb_substr($rawblob,
> mcrypt_enc_get_iv_size($td)); /* CipherText */
> 94 ---> mcrypt_generic_init($td, $realkey, $iv);
> 95 $unblob = mdecrypt_generic($td, $ct);
> 96 mcrypt_generic_deinit($td);
> 97 $pt = mb_substr($unblob, 20);
> 98 $check = mb_substr($unblob, 0, 20);
> 99 if ($check != sha1($pt, true))
> 100 {
> 101 return FALSE;
> 102 } else {
> 103 return $pt;
> 104 }
> 105 }
>
>
> The same code with the same config options is worked fine with apache
> httpd.
>
> Any one can give me a little help ?
> Thanks
>
> Regards,
> Hristo S.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On 2013-09-23 15:42, Aziz Saleh wrote:
Hristo,
Try changing the php.ini config:
mbstring.func_overload 0
See if that helps your issue, more on what it does:
http://php.net/manual/en/mbstring.overload.php [3]
Aziz
On Mon, Sep 23, 2013 at 8:23 AM, Condor <con...@stz-bg.com> wrote:
Hello,
from two days I have strange problem with this param
mbstring.internal_encoding on nginx and php-fpm.
I use php version 5.4.20 and when I setting
mbstring.internal_encoding I have a problem with mcrypt.
NOTICE: PHP message: PHP Warning: mcrypt_generic_init(): Iv size
incorrect; supplied length: 12, needed: 8 in file.php
I setup php.ini file:
zend.multibyte = On
default_mimetype = "text/html"
default_charset = "UTF-8"
mbstring.internal_encoding = UTF-8
and here is function:
85 private function decrypt($blob)
86 {
87 $deckey = $_SESSION['key'];
88 $realkey = sha1($deckey, true);
89 $rawblob = hex2bin($blob); /* binary
blob */
90 $td =
mcrypt_module_open($this->CIPHER, "", MCRYPT_MODE_CFB, "");
91 $iv = mb_substr($rawblob, 0,
mcrypt_enc_get_iv_size($td)); /* IV */
92 if (mb_strlen($iv) <
mcrypt_enc_get_iv_size($td)) return FALSE;
93 $ct = mb_substr($rawblob,
mcrypt_enc_get_iv_size($td)); /* CipherText */
94 ---> mcrypt_generic_init($td, $realkey, $iv);
95 $unblob = mdecrypt_generic($td, $ct);
96 mcrypt_generic_deinit($td);
97 $pt = mb_substr($unblob, 20);
98 $check = mb_substr($unblob, 0, 20);
99 if ($check != sha1($pt, true))
100 {
101 return FALSE;
102 } else {
103 return $pt;
104 }
105 }
The same code with the same config options is worked fine with
apache httpd.
Any one can give me a little help ?
Thanks
Regards,
Hristo S.
Hello,
I just try and no effect after reload the php-fpm.
Regards,
Hristo S.
--- End Message ---
