Database Reference
In-Depth Information
Figure 12.5
Mary now has no access to the user table.
Figure 12.5 shows that Mary no longer has the access that she once had. Instead of
returning the table, MySQL just returns:
Error 1142: select command denied to user: 'Mary@127.0.0.1' for table
'user'
If you are wondering about the number 127.0.0.1, this is just the IP (Internet Protocol)
number that has been allocated for localhost .
Even though the user table has encrypted passwords, it is best not to give normal users
access to it. When given sample passwords and user accounts, it is possible to use software
tools to obtain the password. As you already know the passwords in this table and book
there is little point in trying to hide them, so we will give Mary access to view the contents
of that table again. In the graphical client, type:
GRANT SELECT ON mysql.user
TO Mary@localhost
Back on the MySQL monitor, try to select from the user table again. This time you should
get the whole table back. Notice that because this is a table-level privilege, this time changes
to the user's access became effective immediately. Now let's be more malicious. On Mary's
login, type the following:
DELETE FROM user WHERE user ='mafiu';
Mary will get the error message:
ERROR 1142: delete command denied to user: 'Mary@127.0.0.1' for table
'user'
This is where the GRANT function becomes very useful. If Mary still had all privileges,
she would have just deleted a user. As we had only given her access to the user table for
SELECTing, a DELETE query threw an error, saving the day. The safest rule is to give a user
the minimal access required for them to complete their tasks.
Search WWH ::




Custom Search