In my PHP script, I'm accessing two databases db1 and db2. I have a user myuser#localhost that can access db1 but can't access db2.
When selecting from mysql.user table, there is one record and the host for that user is a wildcard %, there isn't a localhost host.
SELECT user, host FROM mysql.user WHERE user = 'myuser'; give me:
+------------+------+
| user | host |
+------------+------+
| myuser | % |
+------------+------+
1 row in set (0.00 sec)
Looking at GRANTS for that user, I see same permissions for db1 as for db2
SHOW GRANTS FOR 'myuser'#'%';
+-----------------------------------------------------------------------------------------------------------+
| Grants for myuser#% |
+-----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'myuser'#'%' IDENTIFIED BY PASSWORD '*7733323232...' |
| GRANT ALL PRIVILEGES ON `db1`.* TO 'myuser'#'%' |
| GRANT ALL PRIVILEGES ON `db2`.* TO 'myuser'#'%' |
+-----------------------------------------------------------------------------------------------------------+
In my PHP script I can access db1 however I get an error: INSERT command denied to user 'myuser'#'localhost' for table 'HISTORY'.
It says user is myuser#localhost and people suggested adding permission for myuser#localhost however, why does this user have access to db1 and not to db2?
localhost does not match % in MySQL. It seems like it should, but in fact it doesn't. You'd have to separately grant privileges to user#localhost, both for the USAGE privilege, and for the privileges on each database.
Or you can connect as user#127.0.0.1 which does match %. Using the IP address for localhost seems like it should work identically to localhost, but it doesn't. You need to have two lines in the mysql.user table (and also in the mysql.db table in your case) to enable both.
To demonstrate the difference between localhost and 127.0.0.1:
Connecting as mysql -h localhost uses the UNIX socket interface, and bypasses TCP/IP. This can be slightly better for performance, but it has the effect on grant matching described above.
You can force a local TCP/IP connection by connecting as mysql -h 127.0.0.1. Then it will pick up the grants you have made to myuser#%.
So to get the same user, password, and privileges for both the socket interface and the TCP/IP interface, you'd need to run all of the following statements:
GRANT USAGE ON *.* TO 'myuser'#'%' IDENTIFIED BY PASSWORD '*7733323232...'
GRANT USAGE ON *.* TO 'myuser'#'localhost' IDENTIFIED BY PASSWORD '*7733323232...'
GRANT ALL PRIVILEGES ON `db1`.* TO 'myuser'#'%'
GRANT ALL PRIVILEGES ON `db1`.* TO 'myuser'#'localhost'
GRANT ALL PRIVILEGES ON `db2`.* TO 'myuser'#'%'
GRANT ALL PRIVILEGES ON `db2`.* TO 'myuser'#'localhost'
If you haven't done that already, you need to run flush privileges so that mysql knows there was a change and reloads the privileges table for users:
FLUSH PRIVILEGES;
This very likely has nothing to do with GRANTs.
A very common reason for having incorrect access rights is because of default users that exist in MySQL. Specially ones with '' for User (anonymous users) and/or Host in mysql.user table. Because of the way MySQL handles authentication and proxy users, and the sorting rules used on mysql.user table entries, one could end up using an unexpected user than the one they used for authentication.
Use SELECT USER(); to find out the connecting user that was used during authentication and SELECT CURRENT_USER(); to find out the effective user whose privileges apply during the current session.
And from http://dev.mysql.com/doc/refman/5.6/en/connection-access.html
It is a common misconception to think that, for a given user name, all
rows that explicitly name that user are used first when the server
attempts to find a match for the connection. This is not true.
If you are able to connect to the server, but your privileges are not
what you expect, you probably are being authenticated as some other
account.
A mysql.user table similar to following
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| % | root | ... (root from any host)
| % | jeffrey | ... (jeffrey from any host)
| localhost | root | ... (root from localhost)
| localhost | | ... (any user from localhost)
+-----------+----------+-
becomes,
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| localhost | root | ...
| localhost | | ...
| % | jeffrey | ...
| % | root | ...
+-----------+----------+-
whenever the server reads the user table into memory, in order to handle multiple matches.
When a client attempts to connect, the server looks through the rows in sorted order and uses the first row that matches the client host name and user name.
Precedence is given as: values (IP address, host name, user name, etc.) > '%' > ''
Most of the time application server/client is running in the same host as the database, causing the host name to be picked up as localhost during authentication.
mysql -u jeffrey uses jeffrey#localhost which gets matched against ''#localhost instead of jeffrey#%.
Executing $MYSQL_HOME/bin/mysql_secure_installation will remove anonymous users, while securing the installation, alleviating this unexpected behaviour.
Also check:
[1] http://bugs.mysql.com/bug.php?id=36576 (check comment before last)
[2] http://bugs.mysql.com/bug.php?id=69570
Just thought I'd add an answer. I was trying this on ubuntu. Tried the grants, flushes, nothing worked (this is immediately after by apt-get install mysql-server). Just for grins I bounced the server, that worked and my new user can now login. I did:
sudo service mysql restart
I don't know what that worked, but it did.
You must GRANT privileges also to 'myuser'#'localhost':
GRANT ALL PRIVILEGES ON `db1`.* TO 'myuser'#'localhost';
GRANT ALL PRIVILEGES ON `db2_beta`.* TO 'myuser'#'localhost';
Otherwise the anonymous user #localhost created during db install takes precedence among your user with the wildcard hostname (%), as described here:
http://dev.mysql.com/doc/refman/5.5/en/adding-users.html
According to the mysql manual here:
If you modify the grant tables indirectly using account-management
statements such as GRANT, REVOKE, or SET PASSWORD, the server notices
these changes and loads the grant tables into memory again
immediately.
If you modify the grant tables directly using statements such as
INSERT, UPDATE, or DELETE, your changes have no effect on privilege
checking until you either restart the server or tell it to reload the
tables. If you change the grant tables directly but forget to reload
them, your changes have no effect until you restart the server. This
may leave you wondering why your changes do not seem to make any
difference!
This does seem to be true in most cases. However, in my situation I was working with an Amazon Web Services (AWS) RDS mysql instance. After many unsuccessful attempts to grant the user permissions I tried a FLUSH PRIVILEGES and the database was immediately visible to the user. If you come across this while looking for a solution on the Amazon Web Services RDS platform you might want to give this a try and see if it helps.
This SO question contains the most complete solutions to this problem and is the first in most search results so I wanted to add this response for anyone using RDS. Hopefully it will save RDS admins some time.
I have run into the same problem in the past. Have you tried the following?
GRANT ALL ON `db1`.* TO 'myuser'#'%' IDENTIFIED BY PASSWORD '*7733323232...';
GRANT ALL ON `db2`.* TO 'myuser'#'%' IDENTIFIED BY PASSWORD '*7733323232...';
FLUSH PRIVILEGES;
Related
mysql 5.7.22 on centos 7
To be clear I have a root password set up. Usually I log in using
mysql -u root -p
Today I accidentally hit Enter after I only typed
mysql
And I was shocked to find out I had logged in as root user. show grants displays
mysql> 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)
Then I tried
mysql -u root
It still didn't ask for a password for logging in.
Firstly I thought it was some wired setup issue because I was logging in from localhost. However when I tried to login from web browser using serverIP/phpmyadmin and it does ask for root password.
Does anyone know what was going on? Thanks
I assume you are already ssh'd in as root? If you are, then this would be correct as far as I understand from my experience. As you are logged in as the Root user on the server itself, you have complete control over the entire OS and all its applications. There is no 'privilege escalation', as, being the root server user, you can easily change the root password for MySQL (or indeed any aspect of the MySql installation).
Try logging in to the server as a standard user, and try the same, it should not work unless you have an anonymous user set up.
You can view all the users and their hosts with:
SELECT host, user, authentication_string, plugin FROM mysql.user;
This will show you whether there is a password set (there will be an entry in authentication_string) and also the 'plugin' for the db user (re backward compatibility for earlier versions of MySQL)
Here is what I do to check grants for a specific user:
mysql> SHOW GRANTS FOR mmuser1;
+-----------------------------------------------------------------------------------------------------------------+
| Grants for mmuser1#% |
+-----------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'mmuser1'#'%' IDENTIFIED BY PASSWORD '*fesfesfesfes' |
| GRANT ALL PRIVILEGES ON `shopping_mm`.* TO 'mmuser1'#'%'
However, if I do the following:
mysql -ummuser1 -p
I can acccess and query another database (sports). Also, when doing:
SELECT Db,User FROM db;
I can see this Db associated with this user.
How is it possible that is not showing in the Grants table?
As documented under SHOW GRANTS Syntax:
If you specify only the user name part of the account name, a host name part of '%' is used.
It is likely that you have granted permission to your user with an explicit hostname, e.g. 'mmuser1'#'localhost'. As documented later on the same page, this can be verified once connected:
To list the privileges granted to the account that you are using to connect to the server, you can use any of the following statements:
SHOW GRANTS;
SHOW GRANTS FOR CURRENT_USER;
SHOW GRANTS FOR CURRENT_USER();
Or, alternatively, simply inspect CURRENT_USER:
SELECT CURRENT_USER;
Maybe you have a wildcard user that is usually default in Mysql is setup?
Any or % for the user name or host will allow any username/host permission to the DB, like in the picture below
You should remove these users that are usually default in MySQL
This picture is the default accounts that are installed with MYSQL , and all of them should be deleted as soon as you create a new user as none of them are secure, they allow - any username USAGE access to the db's
I'm connecting to the mysql server as user 'someuser'. When I connect to the server from my localbox I get to see all the databases.
However, when I SSH into the server and login with 'someuser' and execute show databases; I only see two: information_schema and test
How can I view all the databases when I SSH into the DB as well?
show grants; shows the below
mysql> show grants;
| Grants for dev#localhost |
| GRANT USAGE ON *.* TO 'someuser'#'localhost' IDENTIFIED BY PASSWORD '*' |
Edit
When I SSH into the server and login to mysql using root then I can see all the databases fine.
GRANT USAGE is not what you want. According to the mysql documentation:
USAGE Synonym 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.1/en/grant.html
You need to grant actual privileges to your "someuser" user for the database the user needs to see. For example, if you grant select privileges on the mysql.*:
GRANT SELECT ON mysql.*
TO someuser#localhost IDENTIFIED BY "somepassword";
FLUSH PRIVILEGES;
Now, someuser connected from localhost will be able to see the mysql database when executing
SHOW DATABASES;
However, you might want to reserve the access to the mysql database for root only.
I have a user 'myuser' and two databases. 'db1' and 'db2'.
'myuser' already has rights to use db1 and I wanted to grant him additional permission to use 'db2' by using the following query:
GRANT ALL ON db2.* TO 'myuser'#'localhost';
After I ran the grant statement, 'myuser' lost the connection to the first database 'db1'
I'm afraid that I used a wrong host name. Instead of 'localhost' I should have used '%'.
When I do:
select host from mysql.user where user = 'myuser';
Now I see two host records '%' and 'localhost' for that user
When I run SHOW GRANT statements I get permissions for different hosts. 'localhost' and '%'.
mysql> SHOW GRANTS FOR 'myuser'#'localhost';
+----------------------------------------------------------------------+
| Grants for myuser#localhost |
+----------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'myuser'#'localhost' |
| GRANT ALL PRIVILEGES ON `beta_version`.* TO 'myuser'#'localhost' |
+----------------------------------------------------------------------+
and
mysql> SHOW GRANTS FOR 'myuser'#'%';
+-----------------------------------------------------------------------------------------------------------+
| Grants for myuser#% |
+-----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'myuser'#'%' IDENTIFIED BY PASSWORD '*6ASDFASDFASDF...'
| GRANT ALL PRIVILEGES ON `myuser`.* TO 'myuser'#'%'
+-----------------------------------------------------------------------------------------------------------+
What happened that caused 'myuser' to not work in my PHP scripts and in phpMyAdmin?
MySQL identifies a user by BOTH the username and the host. When MySQL does the authentication at login, MySQL first looks for a hostname that is an exact match. If it doesn't find an exact match, then it looks for a host containing a '%' wildcard.
When you did the GRANT ... TO myuser#localhost, MySQL created a new user (with no password, because there was no IDENTIFIED BY given in the statement.
Then what happened, when you attempted to login as myuser from the localhost, mysqld tried to find an entry that matched 'myuser'#'localhost' in the mysql.user table and it found it. And the session got the privileges assigned to that user.
(To be a little more precise, mysqld doesn't really look at the contents of the mysql.user table, what it really looks at the in-memory structure, which was populated from the table when it was built. A rebuild of the memory structure is triggered by a GRANT, a REVOKE or a FLUSH PRIVILEGES statement.)
What was happening BEFORE you added that new user, mysqld was looking for an exact match on user and hostname, and didn't find one. But it did find an entry with the '%' wildcard, so it matched to that, so the session got all the privileges granted to the 'myuser'#'%' user.
The two users 'u'#'%' and 'u'#'localhost' are separate and distinct from each other. Privileges must be granted to each user individually. Any privileges granted to 'u'#'%' apply ONLY to that user and NOT to 'u'#'localhost'.
USAGE means "no privileges and that is what you have given your user when connecting from localhost.
I think localhost takes precedence over % so when the user is connecting from localhost that is the grant that will be used.
Grant access to both schemas to % (or localhost if that is what you prefer) and it should be clear and work better.
I have discovered a difference between show grants for user#host and the mysql.db table. Why is this?
How can I resolve this? We are worried about security.
I ran a show grants against users in mysql.users. In mysql.users the user is user#xxx.xxx.xxx.xx and when I run show grants it says GRANT USAGE TO user#xxx.xxx.xxx.xx
This worried me as this user also seems to be able to access a database.
When I looked in mysql.db and information_schema.schema_privileges I can see the same user as user with a host of xxx.xxx.% with full access to that database.
What gives?
Edit - Deeper Explanation:
Here is what I have:
show grants for 'myuser'#'xxx.xxx.xxx.xxx';
It returns:
GRANT USAGE ON *.* TO 'myuser'#'xxx.xxx.xxx.xxx' IDENTIFIED BY PASSWORD 'xxxxxxxxxxxxxxxxx'
If I run:
select host,db,user from mysql.db where user='myuser';
I get:
+----------+------------+------------+
| host | db | user |
+----------+------------+------------+
|xxx.xxx.% | somedb | myuser |
+----------+------------+------------+
Don't worry.
The mysql.user table mitigates specific global privileges on all databases.
If a user is restricted to a specific database, you will only see database specific grants in the mysql.db table. A user restricted to a database does not need SUPER, PROCESS, SHUTDOWN, and privileges like these.
If you create a user withglobal privileges (thus landing the user in mysql.user), you cannot revoke global privileges only to demote the user to a specfic database. If you try to do so with REVOKE commands, you will see the user in mysql.user with the original Y values on all columns and the same user in mysql.db with Y values on database specific privileges.
You must completely drop the user and create the user fresh with the lower privileges.
Here is an example based on the comments
mysql> show grants for advdb#'%';
+-----------------------------------------------------------------------------+
| Grants for advdb#% |
+-----------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'advdb'#'%' IDENTIFIED BY PASSWORD '................' |
| GRANT ALL PRIVILEGES ON `advertpro`.* TO 'advdb'#'%' |
+-----------------------------------------------------------------------------+
The GRANT USAGE simply allows you to know what MD5 password is involved with authentication (if the password is not blank). Note that advdb can login from any IP address and only access the advertpro database.
The user does not need PROCESS privilege unless you want the user to see all processes in the processlist, even the one that belong to others.
The user does not need SUPER privilege unless you want the user to write in a read-only mysql instance, start and stop replication, zap binary logs, and things like these.
The user does not need SHUTDOWN privilege unless you want the user to shutdown mysql from the OS command line user the mysqladmin client program.
To copy the priv you are looking for,
SHOW GRANTS FOR 'user'#'xxx.xxx.xxx.%';
Copy the output to text file
Edit the host to xxx.xxx.xxx.xx
Add a semicolon
Paste that to the other server
OK let's hack that:
UPDATE mysql.db
SET host='xxx.xxx.xxx.xxx'
WHERE user='myuser'
AND host='xxx.xxx.%'
AND db='somedb';
FLUSH PRIVILEGES;
This should it !!!
To dump the MySQL Grants in SQL, you can do pt-show-grants
It is much better to port the mysql grants using pt-show-grants.
Here is my personal emulation of what pt-show-grants does
mysql -hhostaddr -umyuserid -pmypassword --skip-column-names -A -e"SELECT CONCAT('SHOW GRANTS FOR ''',user,'''#''',host,''';') FROM mysql.user WHERE user<>''" | mysql -hhostaddr -umyuserid -pmypassword --skip-column-names -A | sed 's/$/;/g' > MySQLUserGrants.sql