Not able to change privileges with MySQL database - php

Question

I am looking to backup a MySQL database. When the following command is entered into the command line it works:
SELECT * INTO OUTFILE 'backup.txt' FROM table_name;
The file backup.txt is created. All is well.
When the above command is submitted via the MySQL query in a php file:
mysql_query("SELECT * INTO OUTFILE 'backup.txt' FROM table_name");
it does not work. The file backup.txt is not created.
Next, the privileges were looked at and the following command was entered using the command line:
GRANT FILE ON *.* TO 'root'#'localhost';
This command was accepted but the MySQL query still does not work.
The complete php file is shown below:
// connect to db host
//mysql_connect(DATABASE_HOST, DATABASE_USERNAME, DATABASE_PASSWORD)
$connection = mysql_connect("localhost", "mysql -u root", "")
or die('Could not connect: ' . mysql_error($connection));
// select db
$db = mysql_select_db("test", $connection);
// change privileges
mysql_query("GRANT FILE ON *.* TO 'root'#'localhost'");
// create query
$query = "SELECT * INTO OUTFILE 'backup.txt' FROM table_name";
//perform query
mysql_query($query);
// close mysql connection
mysql_close($connection);
Can anybody explain what is happening here and how I can get the MySQL query to work and create the outfile backup.txt.
WampServer on a Windows machine is being used.

Answer 1

At the moment I run mysql command line (MCL), I am an o/s user that has rights (let's call them creds for credentials) at some level to all o/s directories. Let's say the creds don't change for the duration of this code attempt, can't imagine they would. Point is, I am that user with those creds.
Without a path, full or relative just as you did, MCL writes to the data directory for the schema in the outfile call. So for instance on my system at the moment that would be
C:\Users\All Users\MySQL\MySQL Server 5.6\data\so_gibberish
where so_gibberish is the schema/db name that I would have gotten into with the use so_gibberish command or supplied as the db to use upon running mysql command line with a switch. Or it would be some linux path equivalent.
Via the MCL, I would have gotten into a db (use), as opposed to an MCL connect with no use. Meaning that I would not have issued the outfile command prior to getting into a db sandboxed, most likely (I am making the point later as it relates to Error 1046). And your command would have dumped the .txt file there (the above path a ways up) on my system. And it did in my test.
Now on to PHP.
If you are running a PHP script that connects but does not use the mysql_select_db function, then
Error 1046: No database selected
would have returned only if you were running code like the below to check for an error:
<?php
//error_reporting(E_ALL);
//ini_set('display_errors', 1);
...
... (load credential variables used below)
...
$link = mysql_connect($dbhost, $dbuser, $dbpass) or die("Unable to Connect to '$dbhost'");
//mysql_select_db($dbname) or die("Could not open the db '$dbname'");
echo "I made it here<br/>";
$test_query = "SELECT * INTO OUTFILE 'file456.txt' FROM mytable";
$result = mysql_query($test_query);
echo mysql_errno($link) . ": " . mysql_error($link) . "<br>";
mysql_close($link);
Not that people tend to check for errors. I would wager you are not in this call. They just plow foward thinking all is well.
Note though that error_reporting has no impact on this. What does impact it is whether or not you are checking for errors after mysql_query. You can rem out or clear rems and test this theory as I did. So you could be getting the 1046 Error and not know it.
Now there is the case for what o/s users and therefore the creds that the php to mysql process is masquerading as. This is driven by the original setup. Now why is this important? Because that user/those creds can very well be different than those used when at the o/s prompt you did the very first part of this using the MCL.
It is possible that the file is created thru php, but as you are not pathing with a full path to the file, just the filename, it might be sitting somewhere on your system without you knowing it, if you were to check for errors and none arrive. To test this theory, include the above error check after mysql_user without a full path, and do a directory scan to find it.
So in my test, in MCL I write out file123.txt, and in php I write out file456.txt (or whatever). And barring any error messages, I scan the file system to see where they showed up.
You would not be the first person to think OUTFILE failed, only later, maybe months later, find residue files in some directory and have a eureka moment: Oh yeah, I remember those files, what are they doing here?
It is possible that the call simply fails because of a creds issue from PHP, having to do with user or group world or some other setup chmod issue.
Via PHP, fully pathing to the outfile such as /full/path/here/out123.txt can have a good solution if the o/s user masquerading has the creds. But, in hosted environments, you can't simply say make it /tmp/out123.txt, as you will fail with permissions there. So there is no broad brush stroke "plug in this answer" that is going to solve it without a somewhat decent tinkering session by you.
So in summary for PHP, I would look into the following:
The file is being written out, you just don't know where.
The file fails but you don't know it because of no error checking after
mysql_query (such as a general mysql error, no db selected,
whatever).
Creds issue due to the o/s user masquerading from PHP into
mysql and is creds at the o/s file system level required for that
file i/o.
As for the Error 1221 error, as mentioned in comments and link to that part of it, you cannot GRANT FILE on a single db. That answer type was provided here