MySQL account names consist of a user name and a host name. This enables creation of accounts for users with the same name who can connect from different hosts. This section describes how to write account names, including special values and wildcard rules.
In SQL statements such as CREATE
USER, GRANT, and
SET PASSWORD, account names follow
these rules:
Account name syntax is
'.
user_name'@'host_name'
An account name consisting only of a user name is equivalent
to
'.
For example, user_name'@'%''me' is equivalent to
'me'@'%'.
The user name and host name need not be quoted if they are
legal as unquoted identifiers. Quotes are necessary to specify
a user_name string containing
special characters (such as space or -), or
a host_name string containing
special characters or wildcard characters (such as
. or %); for example,
'test-user'@'%.com'.
Quote user names and host names as identifiers or as strings,
using either backticks (`), single
quotation marks ('), or double quotation
marks ("). For string-quoting and
identifier-quoting guidelines, see
Section 9.1.1, “String Literals”, and
Section 9.2, “Schema Object Names”.
The user name and host name parts, if quoted, must be quoted
separately. That is, write
'me'@'localhost', not
'me@localhost'; the latter is actually
equivalent to 'me@localhost'@'%'.
A reference to the CURRENT_USER
or CURRENT_USER() function is
equivalent to specifying the current client's user name and
host name literally.
MySQL stores account names in grant tables in the
mysql system database using separate columns
for the user name and host name parts:
The user table contains one row for each
account. The User and
Host columns store the user name and host
name. This table also indicates which global privileges the
account has.
Other grant tables indicate privileges an account has for
databases and objects within databases. These tables have
User and Host columns to
store the account name. Each row in these tables associates
with the account in the user table that has
the same User and Host
values.
For access-checking purposes, comparisons of User values are case sensitive. Comparisons of Host values are not case sensitive.
For additional detail about grant table structure, see Section 6.2.2, “Grant Tables”.
User names and host names have certain special values or wildcard conventions, as described following.
The user name part of an account name is either a nonblank value
that literally matches the user name for incoming connection
attempts, or a blank value (empty string) that matches any user
name. An account with a blank user name is an anonymous user. To
specify an anonymous user in SQL statements, use a quoted empty
user name part, such as ''@'localhost'.
The host name part of an account name can take many forms, and wildcards are permitted:
A host value can be a host name or an IP address (IPv4 or
IPv6). The name 'localhost' indicates the
local host. The IP address '127.0.0.1'
indicates the IPv4 loopback interface. The IP address
'::1' indicates the IPv6 loopback
interface.
The % and _ wildcard
characters are permitted in host name or IP address values.
These have the same meaning as for pattern-matching operations
performed with the LIKE operator.
For example, a host value of '%' matches
any host name, whereas a value of
'%.mysql.com' matches any host in the
mysql.com domain.
'192.168.1.%' matches any host in the
192.168.1 class C network.
Because IP wildcard values are permitted in host values (for
example, '192.168.1.%' to match every host
on a subnet), someone could try to exploit this capability by
naming a host 192.168.1.somewhere.com. To
foil such attempts, MySQL does not perform matching on host
names that start with digits and a dot. For example, if a host
is named 1.2.example.com, its name never
matches the host part of account names. An IP wildcard value
can match only IP addresses, not host names.
For a host value specified as an IPv4 address, a netmask can be given to indicate how many address bits to use for the network number. Netmask notation cannot be used for IPv6 addresses.
The syntax is
host_ip/netmask
CREATE USER 'david'@'192.58.197.0/255.255.255.0';
This enables david to connect from any
client host having an IP address
client_ip for which the following
condition is true:
client_ip&netmask=host_ip
That is, for the CREATE USER
statement just shown:
client_ip & 255.255.255.0 = 192.58.197.0
IP addresses that satisfy this condition range from
192.58.197.0 to
192.58.197.255.
A netmask typically begins with bits set to 1, followed by bits set to 0. Examples:
192.0.0.0/255.0.0.0: Any host on the
192 class A network
192.168.0.0/255.255.0.0: Any host on
the 192.168 class B network
192.168.1.0/255.255.255.0: Any host on
the 192.168.1 class C network
192.168.1.1: Only the host with this
specific IP address
The server performs matching of host values in account names against the client host using the value returned by the system DNS resolver for the client host name or IP address. Except in the case that the account host value is specified using netmask notation, the server performs this comparison as a string match, even for an account host value given as an IP address. This means that you should specify account host values in the same format used by DNS. Here are examples of problems to watch out for:
Suppose that a host on the local network has a fully qualified
name of host1.example.com. If DNS returns
name lookups for this host as
host1.example.com, use that name in account
host values. If DNS returns just host1, use
host1 instead.
If DNS returns the IP address for a given host as
192.168.1.2, that will match an account
host value of 192.168.1.2 but not
192.168.01.2. Similarly, it will match an
account host pattern like 192.168.1.% but
not 192.168.01.%.
To avoid problems like these, it is advisable to check the format in which your DNS returns host names and addresses. Use values in the same format in MySQL account names.