Correct ways to enter database: To test your new permission setup, try to enter the database using the following commands: (Assuming a password was not established.) Note: Do not establish an account without designating a password, unless you have a very good reason for doing so. ex. Assuming the username is 'dario', and database 'pasta' (Note: this would only work from the localhost, as we have designated pasta to only be reachable via localhost): or, if a password is set:
ex. Assuming the username is 'dario', password 'mamamia', and database 'chicken' (Note: this would only work from both localhost and dv1, as we have designated chicken to be accessible from both): If you have correctly configured the tables, you will see the following message (more or less):
Assuming you have learned tons from this article ;) , and everything went smooth, great. If not, check out the following section, troubleshooting the privilege tables. Troubleshooting: Troubleshooting #1: If: works, but: returns the famous 'Access denied' message, then the wrong hostname is entered in the 'user' table. [see notes below for clarification by Monty] If 'mysql -u username -h hostname databasename' give the error: Access to database denied Then this means that you don't have a row with 'user=username', 'host=hostname' and 'db=databasename' in the db table. There is a problem with the user table. Check the data entered in the user table, and you will most likely find the answer to your problem. [see notes below for clarification by Monty] If you think that you have set up all privileges correct and they still doesn't work, try doing 'mysqladmin reload' and try again. Troubleshooting #3: If a client needs to use LOAD DATA INFILE or SELECT INTO OUTFILE, but keeps getting the 'Access to database denied' command, then the File_priv command isn't set to 'Y' within the 'User' table. Troubleshooting #4: IF within the 'user' table, a '' or '%' has been inserted as the host, the server will look to the 'host' table for the specific privileges. All three privilege tables will sort by non-wild card hosts first, and then by wild-card, choosing the first row that fits the bill. Let's assume we have the following within the 'user' table:
The table will be sorted as follows: localhost/root localhost/any any/dario any/root Thus, which set of privileges will be used if Dario attempts to connect from the localhost? The one with user as dario, right? Wrong. It will use the row with localhost as host and 'any' as user. Thus, pay attention to which privileges are being assigned to users. [see notes below for clarification by Monty] This description is slightly wrong. The host table is only accessed if the db table has a host='' entry. host='%' will match all hosts! Basic Security tips: (READ: IMPORTANT)
blog comments powered by Disqus |
|
|
|
|
|
|
|