| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The MySQL privilege system ensures that all users may perform only the operations allowed to them. As a user, when you connect to a MySQL server, your identity is determined by the host from which you connect and the username you specify. The system grants privileges according to your identity and what you want to do.
MySQL considers both your hostname and username in identifying you
because there is little reason to assume that a given username belongs to
the same person everywhere on the Internet. For example, the user
joe who connects from office.com need not be the same
person as the user joe who connects from elsewhere.com.
MySQL handles this by allowing you to distinguish users on different
hosts that happen to have the same name: you can grant joe one set
of privileges for connections from office.com, and a different set
of privileges for connections from elsewhere.com.
MySQL access control involves two stages:
SELECT
privilege for the table or the DROP privilege for the database.
Note that if your privileges are changed (either by yourself or someone else) while you are connected, those changes will not necessarily take effect with your next query or queries. See 5.5.2 When Privilege Changes Take Effect for details.
The server uses the user, db, and host tables in the
mysql database at both stages of access control. The columns in these
grant tables are shown here:
| Table name | user | db | host |
| Scope columns | Host | Host | Host
|
User | Db | Db |
|
Password | User | ||
| Privilege columns | Select_priv | Select_priv | Select_priv
|
Insert_priv | Insert_priv | Insert_priv |
|
Update_priv | Update_priv | Update_priv |
|
Delete_priv | Delete_priv | Delete_priv |
|
Index_priv | Index_priv | Index_priv |
|
Alter_priv | Alter_priv | Alter_priv |
|
Create_priv | Create_priv | Create_priv |
|
Drop_priv | Drop_priv | Drop_priv |
|
Grant_priv | Grant_priv | Grant_priv |
|
References_priv | References_priv | References_priv |
|
Reload_priv | |||
Shutdown_priv | |||
Process_priv | |||
File_priv | |||
Show_db_priv | |||
Super_priv | |||
Create_tmp_table_priv | Create_tmp_table_priv | Create_tmp_table_priv |
|
Lock_tables_priv | Lock_tables_priv | Lock_tables_priv |
|
Execute_priv | |||
Repl_slave_priv | |||
Repl_client_priv | |||
ssl_type | |||
ssl_cypher | |||
x509_issuer | |||
x509_cubject | |||
max_questions | |||
max_updates | |||
max_connections |
During the second stage of access control (request verification), the server
may, if the request involves tables, additionally consult the
tables_priv and columns_priv tables that provide finer control
at the table and column levels. The columns in these
tables are shown here:
| Table name | tables_priv | columns_priv |
| Scope columns | Host | Host |
Db | Db |
|
User | User |
|
Table_name | Table_name |
|
Column_name |
||
| Privilege columns | Table_priv | Column_priv |
Column_priv | ||
| Other columns | Timestamp | Timestamp |
Grantor |
Each grant table contains scope columns and privilege columns.
Scope columns determine the scope of each entry (row) in the tables, that is, the
context in which the entry applies. For example, a user table entry
with Host and User values of 'thomas.loc.gov' and
'bob' would be used for authenticating connections made to the server
from the host thomas.loc.gov by a client that specifies a username of
bob. Similarly, a db
table entry with Host, User, and Db column values of
'thomas.loc.gov', 'bob' and 'reports' would be used when
bob connects from the host thomas.loc.gov to access the
reports database. The tables_priv and columns_priv
tables contain scope columns indicating tables or table/column combinations
to which each entry applies.
For access-checking purposes, comparisons of Host values are
case-insensitive. User, Password, Db, and
Table_name values are case-sensitive.
Column_name values are case-insensitive in MySQL Version
3.22.12 or later.
Privilege columns indicate the privileges granted by a table entry, that is, what operations can be performed. The server combines the information in the various grant tables to form a complete description of a user's privileges. The rules used to do this are described in 5.4.6 Access Control, Stage 2: Request Verification.
Scope columns contain strings. They are declared as shown here; the default value for each is the empty string:
| Column name | Type |
Host | CHAR(60) |
User | CHAR(16) |
Password | CHAR(16) |
Db | CHAR(64) |
Table_name | CHAR(60) |
Column_name | CHAR(60) |
Before MySQL 3.23, the Db column was CHAR(32) in some tables
and CHAR(60) in others.
In the user, db and host tables, each privilege
is listed in a separate column. Each privilege column is declared as
ENUM('N','Y') and can have a value of 'N' or 'Y';
the default value is 'N'.
In the tables_priv and columns_priv tables, the privilege
columns are declared as SET columns. Values in these columns can
contain any combination of the privileges controlled by the table:
| Table name | Column name | Possible set elements |
tables_priv |
Table_priv
| 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
|
tables_priv |
Column_priv
| 'Select', 'Insert', 'Update', 'References'
|
columns_priv |
Column_priv
| 'Select', 'Insert', 'Update', 'References'
|
Briefly, the server uses the grant tables like this:
user table scope columns determine whether to allow or reject
incoming connections. For allowed connections, any privileges granted in
the user table indicate the user's global (superuser) privileges.
These privileges apply to all databases on the server.
db and host tables are used together:
db table scope columns determine which users can access which
databases from which hosts. The privilege columns determine which operations
are allowed.
host table is used as an extension of the db table when you
want a given db table entry to apply to several hosts. For example,
if you want a user to be able to use a database from several hosts in
your network, leave the Host value empty in the user's db table
entry, then populate the host table with an entry for each of those
hosts. This mechanism is described more detail in 5.4.6 Access Control, Stage 2: Request Verification.
Note that the host table is not affected by the GRANT and
REVOKE statements. Most MySQL installations need not use this table at
all.
tables_priv and columns_priv tables are similar to
the db table, but are more fine-grained: they apply at the
table and column levels rather than at the database level.
Administrative privileges (such as RELOAD or SHUTDOWN)
are specified only in the user table. This is because
administrative operations are operations on the server itself and are not
database-specific, so there is no reason to list these privileges in the
other grant tables. In fact, to determine whether you can perform an
administrative operation, the server need consult only the user table.
The FILE privilege also is specified only in the user table.
It is not an administrative privilege as such, but your ability to read or
write files on the server host is independent of the database you are
accessing.
The mysqld server reads the contents of the grant tables once, when it
starts. Changes to the grant tables take effect as indicated in
5.5.2 When Privilege Changes Take Effect.
When you modify the contents of the grant tables, it is a good idea to make
sure that your changes set up privileges the way you want. For help in
diagnosing problems, see 5.4.8 Causes of Access denied Errors. For advice on general
security issues, see 5.3 General Security Issues.
A useful
diagnostic tool is the mysqlaccess script, which Yves Carlier has
provided for the MySQL distribution. Invoke mysqlaccess with
the --help option to find out how it works.
Note that mysqlaccess checks access using only the user,
db and host tables. It does not check table or column
privileges in the tables_priv or columns_priv tables.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |