Hi Steffen, I don't quite understand all you wrote. On Friday 24 October 2003 09:03, Steffen Dettmer wrote:

...

1) I found that the PHP-script was actually read: supplying some special characters instead of the said parameters to mysql_connect() resulted in a parse error at that line of the script.

How could you manipulate your script to use special characters in mysql_connect? By changing the sources?

Yes, I wrote the script in the first place, why shouldn't I be able to put something like mysql_connect(@@@) into it? Doesn't make sense, of course, but produces a parse error which in turn tells me that I edited the right script and the right connect()-statement: the most primitive way of debugging your programs: put write()-statements whereever you think there might be problems ;-)

Of course you have to make sure that this isn't possible by passing malformed data on the external interfaces. I think there are conditions where variables can be taken from the CGI environment somewhat automatically. I think that is a big pitfall as you might find yourself in using not-sanitized data from untrusted source (browser).

Well, I at least hope the said script is not directly accessible to the outside, short of cracking the system and the like... There is a html-form to put in data, processsing the data is done by some other script, checking these data, and so on.

...

2) However, sensible values seemed never to be used for the connection attempt. (PASSWORD: NO in the error message)

You cannot process sensible values with PHP, except if you have a dedicated (logical) server for each user - at least when using mod_php instead of CGI mode. The reason is the mod_ stuff - performant but insecure: every script runs in the same environment as the same user. PHP may try to put some security from top-level, but this cannot work well because of the complexity.

Oh, sorry, I did not mean something that sophisticated, but mysql_connect(@@@) = nonsense mysql_connect($host,$name,$pass) = sensible

...

3)The trick was to switch off the sql.safe_mode in php.ini. (And that is not connected to the setting of php safe_mode )

Yep, another drawback of mod_php is the global configuration :) Again, if you have one script (-system), then it's no problem of course. Why did you need to set sql.safe_mode off? What does this mean exactly? I would expect that you want sql.safe_mode plus a possibility to connect (however, this seems to be *really* secure :-)).

After having found that the problem was with sql.safe_mode, it was of course easy to google for it.There seems to be basically only one explication: http://www.n3rd.net/ZendInformationCenter/ZendServerCenter/sql_safe_mode.htm Synopsis: If the SQL Safe Mode option is enabled the MySQL and Ingres extensions will ignore the supplied host, user and password information and will use only the default ones. It's also nice to read: (if I only had done it some weeks ago ;-<) http://www.phpbuilder.com/mail/php-install/2001091/0131.php The php-manual hasn't improved since - maybe people where then distracted from reading that posting by something else... Greetings Thomas