Re: [PHP] Secure Password (MySQL) Storage
Raditha Dissanayake wrote: Olaf van der Spek wrote: Hi, Is there a way to store MySQL (or other sensitive data) that will be It should read MySQL passwords. passed to a library in such a way that scripts itself can't access this? A per-vhost store would be ideal. If not, would this be a good idea to implement? Your question is not very clear but if you want to protect your data from prying eyes surely the best way would be to encrypt it? as for security on shared hosting enviorenments we have discussed that topic in the past a few times and the voices of authority strongly believe that it's not possible to completely prevent other users from taking a peek at your code. But then again you could use the turck or zend encoder on it. I'm more worried about the data (in MySQL), not the code. By protecting the MySQL password from being read by scripts directly and only allowing access based on the current vhost, only this vhost can access it's own database and not somebody else. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure Password (MySQL) Storage
Jason Wong wrote: On Thursday 25 November 2004 17:43, Olaf van der Spek wrote: I'm more worried about the data (in MySQL), not the code. By protecting the MySQL password from being read by scripts directly and only allowing access based on the current vhost, only this vhost can access it's own database and not somebody else. Set default MySQL user and password in your virtual host container. Then connect to MySQL without specifying user and password. That's a reasonable solution, but what if multiple SQL users per vhost are needed? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP info: MySQL client API version: 3.23?
In the phpinfo() output, the MySQL client API version is shown as 3.23.49. Shouldn't this be upgraded to 4.1 (generally available/stable)? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP info: MySQL client API version: 3.23?
On Wed, 24 Nov 2004 10:37:19 -0600, Steve Buehler [EMAIL PROTECTED] wrote: At 07:38 AM 11/24/2004, you wrote: In the phpinfo() output, the MySQL client API version is shown as 3.23.49. Shouldn't this be upgraded to 4.1 (generally available/stable)? To do so, you would need to upgrade it. I know I am being a smartaleck ;- when I say this, but it won't upgrade on its own and it won't upgrade just because you upgraded just PHP itself. PHP only reads what the version is from what you have installed, not something that is internal to PHP itself. So if you upgrade your mysql, it will show you a different version when you run your phpinfo. Here is an rpm -qa result from one of my machines: [root]# rpm -qa|grep mysql php-mysql-4.3.2-14.ent mysql-server-3.23.58-1 libdbi-dbd-mysql-0.6.5-5 mysql-devel-3.23.58-2.3 mysql-3.23.58-2.3 My phpinfo client API shows: 3.23.58 Which would be because that is the version of mysql that I am running. My mysql, mysql-server and mysql-devel are all 3.23.58. Only my php-mysql module is 4.3.2-14 But on a up2date Debian Linux Sarge server with MySQL 4.0 and PHP 4.3.9, it still shows 3.23.56 On a Windows XP server with MySQL 4.1 and PHP 4.3.10 (RC1) it shows 3.23.49. So what exactly do I need to upgrade? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP info: MySQL client API version: 3.23?
John Nichel wrote: Steve Buehler wrote: My phpinfo client API shows: 3.23.58 Which would be because that is the version of mysql that I am running. My mysql, mysql-server and mysql-devel are all 3.23.58. Only my php-mysql module is 4.3.2-14 No, this is not the case. If you install with RPM, or you compile from source and only use --with-mysql, the client API is going to be whatever was bundled with PHP at the time. Update your MySQL version, and you're phpinfo will still show the 3.23.58 client library. The only way to change this in PHP4 is to configure and compile php with the version of MySQL _you_ have installedotherwise, it will use the bundled MySQL client. But why is the bundled client not upgraded? Aren't 4.0 and 4.1 clients backwards compatible with 3.23 server? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP info: MySQL client API version: 3.23?
John Nichel wrote: Olaf van der Spek wrote: But why is the bundled client not upgraded? Aren't 4.0 and 4.1 clients backwards compatible with 3.23 server? Why they didn't upgrade the bundle to include the 4.0 release, I don't know. However with the password 'issues' between 4.1 and earlier versions, I'm sure that's a good reason not to bundle the 4.1 client. Isn't that only an issue for 4.1 clients and = 4.1 servers and not for the 'other way around'? I was actually asking because I have a 4.1 server and I couldn't use PHP to connect, because it doesn't support new passwords. Bundled support has been dropped in php5. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP info: MySQL client API version: 3.23?
John Nichel wrote: Olaf van der Spek wrote: snip Isn't that only an issue for 4.1 clients and = 4.1 servers and not for the 'other way around'? I was actually asking because I have a 4.1 server and I couldn't use PHP to connect, because it doesn't support new passwords. It works both ways. You can make your 4.1 client treat passwords as =4.0, and your 4.1 server accept older passwords. If you want the 4.1 Where in the client lib can you change that? I thought = 4.1 clients would automatically use 4.1 passwords if connecting to a 4.1 server. client used in PHP, you'll have to compile it from source and use PHP5. I don't think php4 supports 4.1 (mysql vs mysqli). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Secure Password (MySQL) Storage
Hi, Is there a way to store MySQL (or other sensitive data) that will be passed to a library in such a way that scripts itself can't access this? A per-vhost store would be ideal. If not, would this be a good idea to implement? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Simple math failing - PHP Bug?
Mike Ford wrote: for. (Some early business-oriented computers, and some calculators (especially financial ones) did use a system called binary-coded decimal -- BCD -- to calculate accurately in the sense you mean, but the fact that they were never widely used and have died out almost totally should tell you something about their usefulness.) Wasn't that just a way to store 11 as 0x11 and 56 as 0x56? x86 has BCD instructions too. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Content-Type header required for POST?
Chris Shiflett wrote: --- Olaf van der Spek [EMAIL PROTECTED] wrote: Content-Type is required for any request that has content. It's an HTTP requirement and has very little to do with PHP. Can you explain what you're talking about? I was talking about the request, not about the response. As was I. That's why I used the word request. :-) I'm sorry, I misunderstood 'thas has content'. You'll have a very tough time getting an answer if you can't explain your question. That's the only helpful hint I can provide. The reason I'm asking is that I've got a small application that does a POST request without that header and it used to work fine and not it doesn't. So I was wondering in which version PHP changed this behaviour. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming December 2004http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Content-Type header required for POST?
Chris Shiflett wrote: --- Olaf van der Spek [EMAIL PROTECTED] wrote: Since which version does PHP require the Content-Type header in POST requests? Content-Type is required for any request that has content. It's an HTTP The RFC says should, not is required to. Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type application/octet-stream. requirement and has very little to do with PHP. Can you explain what you're talking about? Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming December 2004http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Content-Type header required for POST?
Hi, Since which version does PHP require the Content-Type header in POST requests? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Content-Type header required for POST?
Chris Shiflett wrote: --- Olaf van der Spek [EMAIL PROTECTED] wrote: Since which version does PHP require the Content-Type header in POST requests? Content-Type is required for any request that has content. It's an HTTP requirement and has very little to do with PHP. Can you explain what you're talking about? I was talking about the request, not about the response. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming December 2004http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP (anti) crash policy?
David Bevan wrote: On October 3, 2004 12:46, Olaf van der Spek wrote: Manuel Lemos wrote: Hello, On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote: I think that making all failed memory allocations recoverable is not viable because more PHP C code that makes memory allocations assumes it only returns if it succeeds. Trying to change that everywhere memory is allocated is and monster job that I doubt that any PHP core developer will agree on doing. You could just create a new function for that: alloc_no_exception There's no need to change every call, you'd only need to change the calls that can take a NULL result. I find it hard to justify such function Why? I think a large number of data handling functions would benefit from such a function. And it'd make PHP more robust. Olaf, PHP is an open source language is it not? Since you're so smart why don't YOU write the code? Because I don't have time to fix every bug (I encounter) in every open source app I use. And I don't know the internals of the PHP code to be sure my patch works and doesn't break anything else. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/03/2004 01:46 PM, Olaf Van Der Spek wrote: Why? I think a large number of data handling functions would benefit from such a function. And it'd make PHP more robust. Because it is an hack to work around the lack of support for detection of corrupted data in zlib. In the end you will be able to handle the failure of zlib but you will not be able to tell whether it failed because the file was too large to decompress or because it failed due to corrupted data. I think it would be better that zlib would be able to detect corrupted data so you could eventually tell the user that the file is corrupted instead of misleading with a message saying there was not enough memory. I know zlib itself doesn't crash due to invalid input. However, even in that case, what do you do with valid input that causes out of memory errors? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/02/2004 06:01 PM, Olaf Van Der Spek wrote: AFAIK PHP runs safely in multi-threaded servers. What you can't expect is that PHP handles abnormal situations caused by flaws in the external libraries that PHP links with. When I link with the same library in a C app, this 'abnormal situation' just results in a normal return from 'gzinflate' with an error value. So why is it a flaw in code from zlib? That is not the problem. The problem is that zlib does not seem to be able to detect and deal with corrupted streams. That leads to requesting absurd amounts of memory that the PHP memory allocator has no way to distinguish whether it is an intentional memory space request or something case by an abnormal situation. It is not up to PHP memory allocator to guess what is going on. So it It indeed isn't. However, it should be possible for the zlib code to say to the allocator: Try to allocate this, if that fails, return an error to me instead of aborting the script. handles like an normal memory allocation, gracefully exits like in any other operations that request space above the configured limits. Gracefully, as in aborting/resetting the TCP/HTTP connection? If zlib was ready to detect corruption it would never request an absurd amount of memory. I do not think it would be wise to change the PHP memory allocator behavior just to deal with zlib inability to detect corruption before asking for exceedingly large memory blocks. I disagree, see above. The flaw is in your code as nobody should be writing infinite recursion programs. No, there is A flaw in my code. That doesn't mean it's THE flaw. If you run a similar program in C it will crash exceeding the acceptable calling stack space. I don't know if you do that in PHP that could be avoided as I don't know if PHP can determine whether the stack space was exceeded. Anyway, the only way to deal with this situation is to let the current How can you claim that's the only way if you don't know whether it's avoidable by PHP? process exit as there is no way to recover from this situation that is evidently a bug of the script, not of PHP. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, I think that making all failed memory allocations recoverable is not viable because more PHP C code that makes memory allocations assumes it only returns if it succeeds. Trying to change that everywhere memory is allocated is and monster job that I doubt that any PHP core developer will agree on doing. You could just create a new function for that: alloc_no_exception There's no need to change every call, you'd only need to change the calls that can take a NULL result. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote: I think that making all failed memory allocations recoverable is not viable because more PHP C code that makes memory allocations assumes it only returns if it succeeds. Trying to change that everywhere memory is allocated is and monster job that I doubt that any PHP core developer will agree on doing. You could just create a new function for that: alloc_no_exception There's no need to change every call, you'd only need to change the calls that can take a NULL result. I find it hard to justify such function Why? I think a large number of data handling functions would benefit from such a function. And it'd make PHP more robust. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote:
AFAIK PHP runs safely in multi-threaded servers. What you can't expect
is that PHP handles abnormal situations caused by flaws in the external
libraries that PHP links with.
When I link with the same library in a C app, this 'abnormal situation'
just results in a normal return from 'gzinflate' with an error value.
So why is it a flaw in code from zlib?
Maybe you should try this script on a multi-threaded webserver. Is this
also caused by flaws in external libraries?
?php
function f()
{
f();
}
f();
?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP (anti) crash policy?
Hi, What is the PHP policy regaring crashes and fatal errors? Are scripts allowed to cause a crash or fatal error of Apache/PHP itself? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 08:54 AM, Olaf Van Der Spek wrote: What is the PHP policy regaring crashes and fatal errors? Are scripts allowed to cause a crash or fatal error of Apache/PHP itself? A PHP served request can only crash if there is a bug that makes it crash. Sure. But what is the answer to my question? Is a (bug in a) script allowed to cause such a crash? Under Apache pre-fork model only the current process that is serving a PHP request will die when the PHP engine crashes. This is why Apache in the pre-fork model is more robust than multi-threaded servers like IIS. Or Apache with the threaded MPM. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 09:41 AM, Olaf Van Der Spek wrote: What is the PHP policy regaring crashes and fatal errors? Are scripts allowed to cause a crash or fatal error of Apache/PHP itself? A PHP served request can only crash if there is a bug that makes it crash. Sure. But what is the answer to my question? Is a (bug in a) script allowed to cause such a crash? Not bugs in a script but rather in the PHP engine. In theory, the PHP engine should never crash but there is no such thing as bug free software. So if I report a script that causes such a crash, it should be marked as bug (and solved)? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 10:00 AM, Olaf Van Der Spek wrote: Is a (bug in a) script allowed to cause such a crash? Not bugs in a script but rather in the PHP engine. In theory, the PHP engine should never crash but there is no such thing as bug free software. So if I report a script that causes such a crash, it should be marked as bug (and solved)? Right. There are instructions on how to provide a backtrace so the bug report contains information useful enough for a developer to try locating and fixing the bug. So what went wrong with this bug report? http://bugs.php.net/bug.php?id=30153 It's marked as bogus, although it provides a script to reproduce the crash. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 10:12 AM, Olaf Van Der Spek wrote: So what went wrong with this bug report? http://bugs.php.net/bug.php?id=30153 It's marked as bogus, although it provides a script to reproduce the crash. That is not a crash. Your script making a PHP function request 600MB of memory. Since it exceeds the configured memory limit, there is no way to recover from memory exhaustion and the script just exits cleanly. It does not crash the current process, even less the Web server. So Apache restarts just because it thinks that's funny? FATAL: erealloc(): Unable to allocate 603602944 bytes [Sun Sep 19 16:11:16 2004] [notice] Parent: child process exited with status 1 -- Restarting. [Sun Sep 19 16:11:16 2004] [notice] Parent: Created child process 3908 [Sun Sep 19 16:11:16 2004] [notice] Child 3908: Child process is running [Sun Sep 19 16:11:16 2004] [notice] Child 3908: Acquired the start mutex. [Sun Sep 19 16:11:16 2004] [notice] Child 3908: Starting 250 worker threads. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: That is not a crash. Your script making a PHP function request 600MB of memory. Since it exceeds the configured memory limit, there is no way to recover from memory exhaustion and the script just exits cleanly. It BTW, I don't agree. It's easily possible to recover from this error. Just return NULL and the gzinflate function will return false. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: On 10/01/2004 10:29 AM, Olaf Van Der Spek wrote: So Apache restarts just because it thinks that's funny? FATAL: erealloc(): Unable to allocate 603602944 bytes [Sun Sep 19 16:11:16 2004] [notice] Parent: child process exited with status 1 -- Restarting. I was not aware that memory allocation failures could make PHP to exit its process but since it seems intentional there must be a reasoning behind that for which I am not the person that should explain. Maybe the reason has to due to the fact that when memory allocation fails, PHP allocation code can't be certain about memory integrity. Why would memory integrity be compromised? It's not like a buffer overflow. Anyway, 600MB memory allocation is not normal in a typical memory application. If it is normal in your application, why don't you just raise the memory limit setting? It would avoid making PHP exit. It's not normal in my app either. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 10:32 AM, Olaf Van Der Spek wrote: That is not a crash. Your script making a PHP function request 600MB of memory. Since it exceeds the configured memory limit, there is no way to recover from memory exhaustion and the script just exits cleanly. It BTW, I don't agree. It's easily possible to recover from this error. Just return NULL and the gzinflate function will return false. If you think that is a good idea, why don't you just write a patch and discuss about it in php-dev mailing list? Because (some of) the PHP developers don't consider this a bug. I doubt the patch would be accepted. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: I was not aware that memory allocation failures could make PHP to exit its process but since it seems intentional there must be a reasoning behind that for which I am not the person that should explain. Maybe the reason has to due to the fact that when memory allocation fails, PHP allocation code can't be certain about memory integrity. But this does mean the policy does allow scripts to crash the engine/server. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: If it is not normal, why don't you just evaluate the expected memory size that is going to be allocated before calling the PHP function that does it and handle the situation within your PHP code? Because I've no idea how gzinflate decides how much memory to allocate. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 11:34 AM, Olaf Van Der Spek wrote: If it is not normal, why don't you just evaluate the expected memory size that is going to be allocated before calling the PHP function that does it and handle the situation within your PHP code? Because I've no idea how gzinflate decides how much memory to allocate. Use worse case estimates. AFAIK, that algorithm can only compress upto 5:1 . If you are taking data from a file, read the file size and multiply by 5 . If the resulting case exceeds the reasonable memory limit, you should not bother to even try opening that way. I know. But the crashing input is just 144 kb. It's an invalid stream, but I do expect my script not to crash when it encounters such a stream. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: Hello, On 10/01/2004 11:20 AM, Olaf Van Der Spek wrote: I was not aware that memory allocation failures could make PHP to exit its process but since it seems intentional there must be a reasoning behind that for which I am not the person that should explain. Maybe the reason has to due to the fact that when memory allocation fails, PHP allocation code can't be certain about memory integrity. But this does mean the policy does allow scripts to crash the engine/server. The way I see it, calling exit() is not a crash. If the code was Indeed, I should've added or fatal error. But from the script's point of view, it's the same as a crash. accessing invalid memory addresses that would cause it segmentation faults, that would crash *ONE* process, you only see an entry in the server error log, the child process would be restarted, but it still would not crash the whole server as you seem to be thinking. Yes, assuming you run on a non-threaded server. But isn't the goal to get PHP4/5 safe for multi-threaded servers too? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP (anti) crash policy?
Manuel Lemos wrote: If you do not think that discussing your alternative solution is worth doing in php-dev, I do not think that keep discussing it php-general is helping anybody. I will post there. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
