revoke all privileges, grant option not working? - mysql

I'm trying to revoke privileges from a given user, say mysqluser1. I try, as root, revoke all privileges, grant option for mysqluser1#localhost;, then I flush privileges. When I check grants, I see that mysquser1 still has privileges. What am I doing wrong?
Below is the excerpt in question:
mysql> show grants for mysqluser1#localhost;
+---------------------------------------------------------------------------------------------------------------------+
| Grants for mysqluser1#localhost |
+---------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'mysqluser1'#'localhost' IDENTIFIED BY PASSWORD '*ALPHANUMSTRINGHERE' |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> revoke all privileges, grant option from mysqluser1#localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> show grants for mysqluser1#localhost;
+---------------------------------------------------------------------------------------------------------------------+
| Grants for mysqluser1#localhost |
+---------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'mysqluser1'#'localhost' IDENTIFIED BY PASSWORD '*ALPHANUMSTRINGHERE' |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql>

#spencer was faster, but I was also going to ask, if you are trying to get rid of all privileges, then why do you need the user?
To remove a user account entirely, use DELETE. As of MySQL 4.1.1, you can also use DROP USER to remove users

The USAGE privilege specifier stands for "no privileges." It is used at the global level with GRANT to modify account attributes such as resource limits or SSL characteristics without affecting existing account privileges.
http://dev.mysql.com/doc/refman/5.5/en/privileges-provided.html

Related

Grant ALL on Database it's not granting any privileges to my specific IP

I'm trying to grant all privileges to a specific IP but when I try to get the list of privileged IPs it always shows only localhost, I followed the instructions in this question but it doesn't do any changes, what am I doing wrong?
MariaDB [(none)]> GRANT ALL ON database.* TO 'root'#'192.168.3.1' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> show grants;
+---------------------------------------------------------------------+
| Grants for root#localhost |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' WITH GRANT OPTION |
| GRANT PROXY ON ''#'' TO 'root'#'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+
2 rows in set (0.00 sec)
mysql> show slave status;
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER,REPLICATION CLIENT privilege(s) for this operation
mysql> show grants;
+------------------------------------------------------------------+
| Grants for root#192.168.1.5 |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'root'#'192.168.1.5' |
| GRANT ALL PRIVILEGES ON `western_star`.* TO 'root'#'192.168.1.5' |
+------------------------------------------------------------------+
2 rows in set (0.00 sec)
Note:
I still get denied even though I logged in with my user remotely and I have the permissions.
mysql> show slave status;
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER,REPLICATION CLIENT privilege(s) for this operation
mysql> show grants;
+------------------------------------------------------------------+
| Grants for root#192.168.1.5 |
+------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'root'#'192.168.1.5' |
| GRANT ALL PRIVILEGES ON `western_star`.* TO 'root'#'192.168.1.5' |
+------------------------------------------------------------------+
2 rows in set (0.00 sec)
Try running this statement:
SHOW GRANTS FOR 'root'#'192.168.3.1' ;
And compare to the return from this:
SHOW GRANTS FOR 'root'#'localhost' ;
SHOW GRANTS shows the grants for the current user.
Note that "root#localhost" is not the same user as "root#192.168.3.1". MySQL identifies a user by both user AND host. (Those are two different users.)
FOLLOWUP
The SUPER and REPLICATION CLIENT privileges are global privileges, not database privileges. Syntax for granting those privileges is ON *.*. For example:
GRANT REPLICATION CLIENT ON *.* TO 'root'#'192.168.1.5' ;

data exporting with MySQLWorkbench

So I'm trying to export a schema/DB out of mysql and I'm getting a weird error.
I also ran several grant commands (see below) which I believe should be enough to let me export the data. On MySQLWorkbench, I logged in as a user mentioned in the grand commands.
Any ideas what I could be doing wrong? Thanks a lot
Error:
Unhandled exception: Error querying security information: Error executing 'SELECT * FROM mysql.user WHERE User='mydb' AND Host='myhost.com' ORDER BY User, Host'
SELECT command denied to user 'mydb'#'my-ip-here' for table 'user'.
SQL Error: 1142
grant commands:
mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> grant all privileges on mydb.* to 'mydb'#'%' identified by 'mypassword';
Query OK, 0 rows affected (0.05 sec)
mysql> grant show databases on *.* to 'mydb'#'%';
Query OK, 0 rows affected (0.01 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)
mysql> show grants for 'mydb'#'%';
+--------------------------------------------------------------------------------------------------------------+
| Grants for mydb#% |
+--------------------------------------------------------------------------------------------------------------+
| GRANT SHOW DATABASES ON *.* TO 'mydb'#'%' IDENTIFIED BY PASSWORD 'mypassword' |
| GRANT ALL PRIVILEGES ON `mydb`.* TO 'mydb'#'%' |
+--------------------------------------------------------------------------------------------------------------+

Why didn't MySQL GRANT create associated user accounts?

I installed Percona Toolkit to use pt-show-grants but it's not showing up all the grants. When I run it I see the following output:
-- Grants dumped by pt-show-grants
-- Dumped from server Localhost via UNIX socket, MySQL 5.5.43-log at 2015-06-11 09:19:19
-- Grants for 'bob'#'12.34.56.78'
GRANT SUPER ON *.* TO 'bob'#'12.34.56.78' IDENTIFIED BY PASSWORD '*4F72B97CAAAAAAAAAAA9C38064C4CCB18CA0DD8';
GRANT SELECT ON `mydb`.* TO 'bob'#'12.34.56.78';
...
In this case, bob is just a user. However all the web sites use specific credentials, for instance developer Bob might have an account for his example.com web site, called bob_examplecom_1. When I show the grants for this account:
mysql> SHOW GRANTS FOR 'bob_examplecom_1'#'localhost';
+-------------------------------------------------------------------------------------------------------------------------+
| Grants for bob_examplecom_1#localhost |
+-------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'bob_examplecom_1'#'localhost' IDENTIFIED BY PASSWORD '*74AE8018AAAAAAAAAAAAAAAABB87B5C83E650CB' |
| GRANT ALL PRIVILEGES ON `bob_core`.* TO 'bob_examplecom_1'#'localhost' WITH GRANT OPTION |
| GRANT ALL PRIVILEGES ON `bob_examplecom_main`.* TO 'bob_examplecom_1'#'localhost' WITH GRANT OPTION |
| GRANT ALL PRIVILEGES ON `bob_blog`.* TO 'bob_examplecom_1'#'localhost' |
+-------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)
However, when I try find an associated user:
mysql> SELECT User, Host FROM mysql.user WHERE User LIKE 'bob\_%';
Empty set (0.00 sec)
Presumably the original GRANTs didn't create an associated user account? Also note that the above is an example of one web site, where there are many sites. I'm probably missing something here but I expected to see NO_AUTO_CREATE_USER in a mode:
mysql> SELECT ##GLOBAL.sql_mode;
+-------------------+
| ##GLOBAL.sql_mode |
+-------------------+
| |
+-------------------+
1 row in set (0.00 sec)
So, my problem is I want to use pt-show-grants to create an SQL file of the many GRANTs that need running for a new user on this development server, but I can't figure out how. Do I need to retrospectively create user accounts that match up to the GRANTs? Should I change some settings and/or setup accounts differently in the future?
Update: I just ran FLUSH PRIVILEGES and all the GRANTs that were working that had no associated accounts in mysql.user vanished. Does this mean they're gone for good, and all need to be recreated manually? Why would such a thing happen? I've looked through the MySQL command history and see no commands that would have dropped these accounts in the past. The uptime on this server is over 400 days and the sites have all worked in that time with little messing about.
Update 2: I had to recreate all the accounts. This time, with the GRANT USAGE and then granting privileges did indeed create the user accounts. My question is now a simple one:
Why didn't MySQL GRANT create associated user accounts when performing GRANTs?
Based on your description of the observed behavior, it sounds as if rows were removed from the mysql.user table, using a DELETE statement, rather than a DROP USER statement.
Changes made to the privilege tables (mysql.user, mysql.db, et al.) via DML statements (DELETE, INSERT, UPDATE), do not take effect immediately. MySQL has already read those tables, and the information is held in memory. Checks of privileges go against the in memory store; MySQL doesn't check the contents of the tables.
So it's possible to make changes to the mysql.user table, and not have those changes reflected in the effective privileges.
The FLUSH PRIVILEGES statement is what causes MySQL to re-read all the privilege tables, and rebuild the "in memory" store of privilege information.
To answer your question(s)...
Q: Presumably the original GRANTs didn't create an associated user account?
Q: Why didn't MySQL GRANT create associated user accounts when performing GRANTs?
A: The GRANT for a "new" user did create the user account, if it completed successfully. The appropriate row was added to the mysql.user table, and the privileges became effective (the change was also applied to the "in memory" privilege structure.
Q: Does this mean they're gone for good, and all need to be recreated manually?
A: Yes. If the rows are not in the mysql.user table, then those will need to be recreated. The rows in the mysql.user, mysql.db tables could be restored from a backup.
Q: Why would such a thing happen?
A: As mentioned earlier, someone may have inadvertently run a DELETE statement against mysql.user table. (It's also possible a TRUNCATE, or a DROP and CREATE. (Executing the SQL from mysqldump script that includes DROP TABLE statement, to reload the table from an old backup?)
If operations like that weren't performed on the table, then another possibility is that MyISAM table became corrupted, and the repair of the corruption caused the loss of rows. (A known issue with MyISAM tables; and one of the reasons we take backups of the databases, and test restores.)
Here's a demonstration of the behavior... removing a row from mysql.user is not immediately reflected in the effective privileges:
Verify user does not exist:
mysql> SELECT USER, HOST FROM mysql.user WHERE USER LIKE 'bob' ;
Empty set (0.00 sec)
mysql> SHOW GRANTS FOR 'bob'#'192.168.11.121' ;
ERROR 1141 (42000): There is no such grant defined for user 'bob' on host '192.168.11.121'
Create user with GRANT statement:
mysql> GRANT SELECT ON ergo.* TO 'bob'#'192.168.11.121' IDENTIFIED BY 'mysecret';
Query OK, 0 rows affected (0.00 sec)
Check contents of mysql.user table and effective privileges:
mysql> SELECT USER, HOST FROM mysql.user WHERE USER LIKE 'bob' ;
+------+----------------+
| USER | HOST |
+------+----------------+
| bob | 192.168.11.121 |
+------+----------------+
1 row in set (0.00 sec)
mysql> SHOW GRANTS FOR 'bob'#'192.168.11.121' ;
+-----------------------------------------------------------------------------------------------------------------+
| Grants for bob#192.168.11.121 |
+-----------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'bob'#'192.168.11.121' IDENTIFIED BY PASSWORD '*440A4F469FD488A1C73204842936CC18A62A7D7F' |
| GRANT SELECT ON `ergo`.* TO 'bob'#'192.168.11.121' |
+-----------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
Remove row from mysql.user table (using DML operation and not a DROP USER statement)
mysql> DELETE FROM mysql.user WHERE USER = 'bob' AND HOST = '192.168.11.121';
Query OK, 1 row affected (0.00 sec)
Row is gone from mysql.user table, but privileges are still effective:
mysql> SELECT USER, HOST FROM mysql.user WHERE USER LIKE 'bob' ;
Empty set (0.00 sec)
mysql> SHOW GRANTS FOR 'bob'#'192.168.11.121' ;
+-----------------------------------------------------------------------------------------------------------------+
| Grants for bob#192.168.11.121 |
+-----------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'bob'#'192.168.11.121' IDENTIFIED BY PASSWORD '*440A4F469FD488A1C73204842936CC18A62A7D7F' |
| GRANT SELECT ON `ergo`.* TO 'bob'#'192.168.11.121' |
+-----------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
Force MySQL to rebuild privileges, reading from mysql.user table...
mysql> FLUSH PRIVILEGES ;
Query OK, 0 rows affected (0.00 sec)
Privileges are no longer effective:
mysql> SHOW GRANTS FOR 'bob'#'192.168.11.121' ;
ERROR 1141 (42000): There is no such grant defined for user 'bob' on host '192.168.11.121'

After enable remote access, ROOT lost privileges and grant privilege to ROOT doesn't work

AFTER update user set host='%' where user='root, I lost some of the privileges from my MySQL root user. So I stopped the server and started it with --skip-grant-tables
msqld --skip-grant-tables
and I tried
mysql>update mysql.user set grant_priv = 'Y' where user = 'root';
Query OK, 0 rows affected (0.00 sec)
mysql>FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
This doesn't work for me. When I log in as root, I still can't see the MYSQL database.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| test |
+--------------------+
2 rows in set (0.00 sec)
Please help. I've tried all the solutions still can't restore the privileges for ROOT, always got the "0 row affected" result.
Try
GRANT ALL PRIVILEGES ON *.* TO 'root'#'%' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Update
Run this command to check your current privileges
SHOW GRANTS FOR CURRENT_USER;
It is a bad practice to insert/update/delete from mysql.* tables and information_schema.* tables using direct SQL DML statements.
Update 2
Can you post the results of this command
SELECT (
Host,
Grant_priv,
Super_priv
)
FROM mysql.user
WHERE user = 'root';
All of the _priv columns should have a value Y. And the Host should be localhost.

MySQL: Grant Privileges followed by Flush Privileges has not effect, no error (logged in as root)

I and a teammember are stumped because commands to grant privileges to a remote user are failing, but with no error. The new user was successfully added to mysql.user using CREATE USER, but GRANT PRIVILEGES followed by FLUSH PRIVILEGES isn't affecting the grants table. Both these commands are supposed to say 'Query OK. 0 rows affected,' which they do. But then SHOW GRANTS doesn't show the new privileges, nor can we log in with that username from the specified remote ip. Can anyone explain the following behavior?
mysql> SELECT CURRENT_USER(); ///I'm definitely in as root user
+----------------+
| CURRENT_USER() |
+----------------+
| root#localhost |
+----------------+
1 row in set (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON *.* TO 'myNewUser'#'remoteIP'; //grant to existing user
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW GRANTS;
| Grants for root#localhost
| GRANT ALL PRIVILEGES ON *.* TO 'root'#'localhost' IDENTIFIED BY PASSWORD '*////TakenOut///' WITH GRANT OPTION |
| GRANT PROXY ON ''#'' TO 'root'#'localhost' WITH GRANT OPTION
2 rows in set (0.00 sec)
I would expect a 3rd row with privileges for 'myNewUser'.
The SHOW GRANTS statement shows the grants for the current user. In your case, for root#localhost. So you shouldn't be expecting to see a third row with privileges for myNewUser.
Rather, query the mysql.user table...
SELECT * FROM mysql.user WHERE User = 'myNewUser'
I would verify that the password is set for 'myNewUser'#'remoteip'. (MySQL identifies a "user" by the combination of the username and the host. The user 'myNewUser'#'thisip' is a different user than 'myNewUser'#'thatip'.)
Also, we have this setting in our MySQL my.cnf files:
# Disable DNS Lookup (use IP addresses only)
skip-name-resolve
So we use IP addresses, rather than hostnames. (This avoids the connect problems that occur when DNS can't do a DNS reverse lookup from the IP address to get a hostname.)
http://dev.mysql.com/doc/refman/5.1/en/host-cache.html
Bottom line is that MySQL does a "reverse lookup" of an IP address to get a hostname. If it can't get a hostname for a given IP address, connections from the IP address will fail.