[ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |