Hello list, I've got that problem with mysql + php. Both run under SuSE 8.2, (php 4.3.1 as Apache module, mysql vers. 11.18). I have tried to follow the instructions, giving 'root' a password, setting up a mysql-user with fewer privileges etc. I have set up a table in db 'test' and put in some data. Now, when I try to connect via a php-script, access is denied: mysql_connect() [function.mysql-connect]: Access denied for user: 'roth@localhost' (Using password: NO) The first strange thing is that the username supplied to mysql_connect() in the script is not 'roth' (although this username exists on the system). Then I was somewhat successful by not supplying anything to the mysql_connect() function - until I realized that by default, there is a mysql-user '@localhost' without a password. Giving a password to '@localhost' of course leads with the access denial as above. I also found that the message ' Using password: NO' appears if you say on the commandline: 'mysql -u user' If you instead put int the -p ('mysql -u user -p '), you will be asked for the password, as it should be. But how can you do that via the web/apache/php? The only advice I've found is exactly what I did: to put the relevant data into the php script and use them in mysql_connect(). Somewhere I read that in case of an empty mysql_connect(), the identity of the apache-user will be used as the default mysql-user. But apache is definitly not running as the user that appears in the complaint above. Checking php.ini, I see that php runs in safe_mode. Well, I'm somewhat confused and would appreciate your help Thomas
Hello, I think I fixed my problem with mysql. So in case someone runs into the same troubles: 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. 2) However, sensible values seemed never to be used for the connection attempt. (PASSWORD: NO in the error message) 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 ) Best regards, Thomas
* Thomas Roth wrote on Thu, Oct 23, 2003 at 16:38 +0200:
I think I fixed my problem with mysql.
Well, as this is a security list, let's discuss a little :)
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? 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).
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.
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 :-)). Thank you for your mail. It is great when people not only ask questions but also share the solution when they found it. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (2)
-
Steffen Dettmer -
Thomas Roth