March 21st, 2000, 09:13 PM
My web hosting tech support are not understanding my problem. Basically my
PHP scripts query my DB. To do so, I have to put my DB password directly into my .php3 files. From the MySQL manual, I should be able to keep a .my.cnf file in my home dir (-rw-------) which will be consulted instead
of keeping passwords in scripts.
When I ask tech support why my .cnf file is not consulted, they reply with:
> our version of mysql is
> mysql Ver 9.38 Distrib 3.22.30
> this version doesnt have the
> grant_priv field in the user
> table of the mysql database
> (the main mysql config db)
> thus we cant give you grant
> capabilities, further the
> .my.cnf requires the file_prv
> to be defaulted to yes, the
> head sys admin told me to make
> these config to no , thus a
> priv overwrite using a .cnf
> file is not possible.
Can anyone verify this as a legit 'excuse' or
provide me an alternative to having my DB password in a PHP script? Needless to say I'm not thrilled to have passwords in scripts as there must be a way users could retrieve them and view (though I tried using 'wget' on one of my scripts and it did not reveal my PHP code verbatim). At a minimum, another user on my hosting machine would have the ability to view my PHP scripts and thus could drop my DB.
Please offer some advice I can tell the
not-so-great tech support. Thanks!!
March 22nd, 2000, 06:00 PM
Try keeping your sensitive stuff in an "include" directory above document root. If your site is located at /www/users/yoursite/HTML then make the directory /www/users/yoursite/include and add a text file called db.inc or similar. db.inc might look like...
function LinkUp($hostname, $username, $password)
$mysql_link=mysql_connect($hostname, $username, $password);
Then in your PHP script,use
$link=LinkUp($hostname, $username, $password);
Hope this helps
March 24th, 2000, 11:48 AM
and what file permissions would I want to give this 'include' file? I just created a test file and gave it 644 permissions and when I pull the file remotely using 'wget', I can view the password and everything. This is worse than putting the password in the script the original way because at least PHP does some sort of processing to hide some of its raw code.
Any other thoughts?
March 24th, 2000, 12:59 PM
Just use a file that ends in ".php3" so that it gets interpreted by the mod_php before geting sent to the browser. That should result in a blank page being returned if someone tries to read your include file...
[This message has been edited by Erik Lindsley (edited March 24, 2000).]
March 24th, 2000, 01:17 PM
that _does_ solve the problem with wget returning something useful but does not solve the other issue that other users of my machine can view this included .php3 file. Therefore the real people I am attempting to thwart can still drop my DB since they can plainly view my passwd. I really need a solution that works with the intended .my.cnf configuration file (just as the folks who wrote MySQL suggest). Perhaps I need to spend more time learning about this "file_prv" variable that my hosting company has set to No when I believe it is intended to be Yes.
Any admins out there know why a company would reset this var to No? Any good security reasons? - seems it actually defeats the purpose of (user) security not improve.
March 27th, 2000, 01:34 AM
The contents of your include file do not need to be world-readable to include into a document presented to the browser. As long as the PHP process can read the include file, you can keep the permissions to a minimum. If other users on the system can still view this document, there is something wrong with that system. And if this is a standard Unix setup, you should have a directory below your HTML documents directory where you can place this file, where http users (or wget) could never download it from the web.