php-general Digest 23 Sep 2013 18:36:21 -0000 Issue 8374
php-general Digest 23 Sep 2013 18:36:21 - 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
--
---BeginMessage---
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.plwrote:
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.0 +0200
Modify: 2013-08-12 21:38:27.0 +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.phphttp://html.galeria.michal.waw.pl/gallery3-3.0.x/test.phpon
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---
---BeginMessage---
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.plwrote:
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:
Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)
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.plwrote: 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.0 +0200 Modify: 2013-08-12 21:38:27.0 +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.phphttp://html.galeria.michal.waw.pl/gallery3-3.0.x/test.phpon 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
Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)
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.plwrote:
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.0 +0200
Modify: 2013-08-12 21:38:27.0 +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.phphttp://html.galeria.michal.waw.pl/gallery3-3.0.x/test.phpon
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Friday's Question
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm
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
Re: [PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm
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
Re: [PHP] Problem with mbstring.internal_encoding, mcrypt and php-fpm
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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)
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.0 +0200 Modify: 2013-08-12 21:38:27.0 +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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
I have read your mail twice and still I could not get what you want exactly. can't get the structure of the email either although you elaborate it in details. you have said something about human rights that I couldn't understand why? but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org m...@nikha.org wrote: Hello all, im posting this here, because the bug report system of php.net is not right place for my problem. It's not a bug, but a wish - an I found there no wishlist option at all. I'm running my own webmail-client, written in PHP. It is stable, fast and pretty, showing the full power of the PHP imap section. Of course it presents paginated content lists for every mailbox the user may open. These lists tell him some usefull things about every mail actually listed: Sender, date, subject, size and (eventually) flags. All these things are nicely delivered by the function imap_fetch_overview() The same could be done by calling imap_headerinfo() for every single mail, but fetch_overview seems to be faster, because it does it at once for the whole batch. BUT NONE OF THEM returns any information about the MIME-Type of the mail! Since the user of my webmail client has the intrinsic, natural born an general human right to KNOW whether some mail in his mailbox has attachments or not, I'm forced to do very ugly things. My script calls additionally for every (!) actually listed mail imap_fetchbody($connect, $msg_no, 0) - where $connect holds the result of imap_open(). That gives me the mail header, the script reads the line starting with Content-Type: and returns its content. Evaluating this against mixed or alternative we have finaly what we want: This mail has attachments! Or is written in HTML, what is even more we wanted! Works fine, but is ugly. First fetch_overview parses all mail headers, then they are fetched again to be parsed for the MIME-Type. I could just omit fetch_overview and read the headers by my own means, that whould be faster, but then I loose the size information, that is NOT (and cannot) be part of the mail header! If I want to have both, size and MIME-Type, and I WANT to have both, respecting the intrinsic, natural born and general human rights of my user, im must call both, overview and fetchbody. My question is this: Is there a better solution? Or is there someone that knows someone among the PHP-Developpers to suggest them an improvement of the functions imap_fetch_overivew() and imap_headerinfo(). Please, Please, add the MIME-Type to your fantastic object collections! BTW: It's really easy. Read the Content-Type-Line! Sorry... Hope, somebody has an idea, my regards, Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Apache
Tim Streater am Montag, 23. September 2013 - 12:56: 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 You are right, but unfortunately filenames ARE metadata for Apache. Would be better, if they were not, and just identifiers... Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
I have read your mail twice and still I could not get what you want exactly. can't get the structure of the email either although you elaborate it in details. you have said something about human rights that I couldn't understand why? but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org m...@nikha.org wrote: Hello all, im posting this here, because the bug report system of php.net is not right place for my problem. It's not a bug, but a wish - an I found there no wishlist option at all. I'm running my own webmail-client, written in PHP. It is stable, fast and pretty, showing the full power of the PHP imap section. Of course it presents paginated content lists for every mailbox the user may open. These lists tell him some usefull things about every mail actually listed: Sender, date, subject, size and (eventually) flags. All these things are nicely delivered by the function imap_fetch_overview() The same could be done by calling imap_headerinfo() for every single mail, but fetch_overview seems to be faster, because it does it at once for the whole batch. BUT NONE OF THEM returns any information about the MIME-Type of the mail! Since the user of my webmail client has the intrinsic, natural born an general human right to KNOW whether some mail in his mailbox has attachments or not, I'm forced to do very ugly things. My script calls additionally for every (!) actually listed mail imap_fetchbody($connect, $msg_no, 0) - where $connect holds the result of imap_open(). That gives me the mail header, the script reads the line starting with Content-Type: and returns its content. Evaluating this against mixed or alternative we have finaly what we want: This mail has attachments! Or is written in HTML, what is even more we wanted! Works fine, but is ugly. First fetch_overview parses all mail headers, then they are fetched again to be parsed for the MIME-Type. I could just omit fetch_overview and read the headers by my own means, that whould be faster, but then I loose the size information, that is NOT (and cannot) be part of the mail header! If I want to have both, size and MIME-Type, and I WANT to have both, respecting the intrinsic, natural born and general human rights of my user, im must call both, overview and fetchbody. My question is this: Is there a better solution? Or is there someone that knows someone among the PHP-Developpers to suggest them an improvement of the functions imap_fetch_overivew() and imap_headerinfo(). Please, Please, add the MIME-Type to your fantastic object collections! BTW: It's really easy. Read the Content-Type-Line! Sorry... Hope, somebody has an idea, my regards, Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)
W dniu 2013-09-23 10:06, Negin Nickparsa pisze: regardless of you, saying they have same permissions I think they do not have the same permission The reason was 64-bit inode number. PHP can't stat() files with 64-bit nodes, at lease on 32-bit system. Regards Michał -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] filesize() fails on file and works on it's copy (same permissions, same directory)
W dniu 2013-09-23 17:24, Tamara Temple pisze: 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? You're right - 64-bit inode number was a cause. I had to add inode32 mount option (XFS). Regards Michał -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
On Mon, 2013-09-23 at 20:36 +0200, Domain nikha.org wrote:
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
No, no, no! That is not a good stand-in for fundamental security
principles!
This is a better method for ensuring an image is really an image:
?php
if(isset($_FILES['file']))
{
list($width, $height) = getimagesize($_FILES['file']['tmp_name']);
if($width $height)
{
$source = imagecreatefromjpeg($_FILES['file']['tmp_name']);
$dest = imagecreatetruecolor($width, $height);
imagecopyresampled($dest, $source,
0, 0, 0, 0,
$width, $height, $width,
$height);
imagejpeg($dest, basename($_FILES['file']['tmp_name']));
}
else
echo {$_FILES['file']['name']} is not a jpeg;
}
?
form enctype=multipart/form-data method=post
input type=file name=file/
input type=submit name=submit value=submit/
/form
Obviously it's only rough, and checks only for jpeg images, but that's
easy to alter. I've just tested this with a regular jpeg, the same jpeg
with PHP code concatenated onto the end (which still appears to be a
valid image to viewing/editing software) and a pure PHP file with a .jpg
extension. In the case of the first 2, a new jpeg is generated with the
same image and without the code. The third example just echoes out an
error.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] No MIME-Type in imap_fetch_overview()
What Niklaus wishes for is a way to detect if an email message contains an attachment by just reading the headers (correct me if I am wrong). This isn't really a PHP issue. In any language you can't really figure out if an email has an attachment by just looking at the headers, you need to check the body. You can try to infer by using the content-type or the size, but that isn't 100% valid. Aziz On Mon, Sep 23, 2013 at 2:59 PM, Negin Nickparsa nickpa...@gmail.comwrote: I have read your mail twice and still I could not get what you want exactly. can't get the structure of the email either although you elaborate it in details. you have said something about human rights that I couldn't understand why? but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Sincerely Negin Nickparsa On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org m...@nikha.org wrote: Hello all, im posting this here, because the bug report system of php.net is not right place for my problem. It's not a bug, but a wish - an I found there no wishlist option at all. I'm running my own webmail-client, written in PHP. It is stable, fast and pretty, showing the full power of the PHP imap section. Of course it presents paginated content lists for every mailbox the user may open. These lists tell him some usefull things about every mail actually listed: Sender, date, subject, size and (eventually) flags. All these things are nicely delivered by the function imap_fetch_overview() The same could be done by calling imap_headerinfo() for every single mail, but fetch_overview seems to be faster, because it does it at once for the whole batch. BUT NONE OF THEM returns any information about the MIME-Type of the mail! Since the user of my webmail client has the intrinsic, natural born an general human right to KNOW whether some mail in his mailbox has attachments or not, I'm forced to do very ugly things. My script calls additionally for every (!) actually listed mail imap_fetchbody($connect, $msg_no, 0) - where $connect holds the result of imap_open(). That gives me the mail header, the script reads the line starting with Content-Type: and returns its content. Evaluating this against mixed or alternative we have finaly what we want: This mail has attachments! Or is written in HTML, what is even more we wanted! Works fine, but is ugly. First fetch_overview parses all mail headers, then they are fetched again to be parsed for the MIME-Type. I could just omit fetch_overview and read the headers by my own means, that whould be faster, but then I loose the size information, that is NOT (and cannot) be part of the mail header! If I want to have both, size and MIME-Type, and I WANT to have both, respecting the intrinsic, natural born and general human rights of my user, im must call both, overview and fetchbody. My question is this: Is there a better solution? Or is there someone that knows someone among the PHP-Developpers to suggest them an improvement of the functions imap_fetch_overivew() and imap_headerinfo(). Please, Please, add the MIME-Type to your fantastic object collections! BTW: It's really easy. Read the Content-Type-Line! Sorry... Hope, somebody has an idea, my regards, Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache
On Sep 23, 2013, at 1:36 PM, Domain nikha.org m...@nikha.org wrote: Better solutions? One I have used, and continue to use in Apache environments, is place uploads only in a place where they cannot be executed by turning off such options and handlers in that directory. This is *in addition* to untainting files and names of uploaded files. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
Negin Nickparsa am Montag, 23. September 2013 - 20:59: I have read your mail twice and still I could not get what you want exactly. Sorry for my bad english! What I want is, that the users of my webmail client can see at a glance, if mails in their mailboxes have attachments or not. (Thats a human right! But of course I was joking... It's simply nice to provide this information and should be done) but if you want to get the type of files fetch the structure and then you can use disposition string, find the attachment and then return the array. Yes, I could do even that! But this is worse! Imagine, you do this in the overview of the mailbox content! This can be hunderds of mails! My script paginates this stuff in blocks of 16 (or something) mail headers, but even then you have an huge overhead. Why? Because, first you must collect the sender and subject information. This is done by imap_fetch_overview(), parsing the mailheaders and grabing some server data, like arrival date, size and flags. Fine, but you still know nothing about attachments! You must do something more. OK? You whould run imap_fetchstructure(), but sorry, that's the wrong time and place. You will need this monster object only when the user _reads_ some specific mail. At the moment, we are not reading, but collecting mails to present them in the mailbox overview. My script modestly fetches the mailheaders again to read the Content-Type-line. That's quite fast, works fine, but is stupid, because this headers were fetched and parsed just before! I ask you, and all PHP developpers: Why the hell this function does not parse this line too? (a part of so much others of less importance) The same is true for imap_headerinfo(). And: of course this Content-Type-line provides by far not the complete MIME-structure as imap_fetchstructure() does, but, as said, we don't need this at the moment. The result is a script, that I self whould not describe as good practice because of it's duplicated parsing of the same string, but I found no other way yet. That's my problem, you see? Sincerely Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] No MIME-Type in imap_fetch_overview()
Aziz Saleh am Montag, 23. September 2013 - 22:06: What Niklaus wishes for is a way to detect if an email message contains an attachment by just reading the headers (correct me if I am wrong). Yes, that's what I'm seeking :-) This isn't really a PHP issue. In any language you can't really figure out if an email has an attachment by just looking at the headers, you need to check the body. You can try to infer by using the content-type or the size, but that isn't 100% valid. That's like radio Eriwan: In principle you are right! BUT: I want not show the whole MIME-structure in the mailbox overview! That whould be absurd, and indeed could only be done by reading the body. Nevertheless we have in the primary header of any MIME compliant message the line Content-Type. (We have it also in the headers of the attached parts, but that is not intresting now) In this primary header (fetched by imap_fetchbody($mailbox, $msg_no, 0)) the leading part of the MIME-type description can have only two values: text or multipart. Right? I'm sure you will never find other values in the _primary_ header. That's the first decision for your script. text: no attachment, multipart: attachment. No matter the subtype-value after the slash, you have what I want! And ONLY by looking on the header. And this ist 100% valid, because it follows logically from the imap- and MIME-rfc's. About malformed messages violating the protocols we discuss next year, you agree? :-) You may evaluate the subtype after the slash. If the type is multipart, you will find mixed, alternative, related or digest, if the type is text, you will have plain or html as subtype. May be there are more subtypes on the way, but all these are optional for the primary job, a decent mailbox overview must do: tell the user, whether there are attachments or not. My own webmail client does this job pretty good, but it violates my own standard of good practice. Whether imap_fetch-overview() nor imap_headerinfo are reading the Content-Type-line while parsing much other header lines of minor importance. My script must refetch the mailheaders to do that! This is an ugly overhead I wish to avoid. BTW: the squirrelmail-staff, leading in the PHP-webmail-world, just ignores the whole imap-extension of PHP. Instead, they talk low level with the server. But this way is a little bit too hard for me... Therefore my pledge to all involved into the development of the fabulous PHP framework, section imap: Please ad the primary MIME-type to the objects returned by fetch_overview and headerinfo! It's so ridiculous simple: read the Content-Type-line in the primary mailheader as I must do afterwards, only because you do not! Niklaus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
