8.2.4 Specifying Account Names

MySQL account names consist of a user name and a host name, which enables creation of distinct accounts for users with the same user name who connect from different hosts. This section describes the syntax for account names, including special values and wildcard rules.

In most respects, account names are similar to MySQL role names, with some differences described at Section 8.2.5, “Specifying Role Names”.

Account names appear in SQL statements such as CREATE USER, GRANT, and SET PASSWORD and follow these rules:

• Account name syntax is 'user_name'@'host_name'.

• The @'host_name' part is optional. An account name consisting only of a user name is equivalent to 'user_name'@'%'. For example, 'me' is equivalent to 'me'@'%'.

• The user name and host name need not be quoted if they are legal as unquoted identifiers. Quotes must be used if a user_name string contains special characters (such as space or -), or a host_name string contains special characters or wildcard characters (such as . or %). For example, in the account name 'test-user'@'%.com', both the user name and host name parts require quotes.

• 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 11.1.1, “String Literals”, and Section 11.2, “Schema Object Names”. In SHOW statement results, user names and host names are quoted using backticks (`).

• 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'@'%', although this behavior is now deprecated.)

• 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 the properties of user names and host names as stored in the grant tables, such as maximum length, see Grant Table Scope Column Properties.

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 (the 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.

• Use of the % and _ wildcard characters is permitted in host name or IP address values, but is deprecated as of MySQL 8.0.35, and thus subject to removal in a future version of MySQL. These characters 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. '198.51.100.%' matches any host in the 198.51.100 class C network.

  Because IP wildcard values are permitted in host values (for example, '198.51.100.%' to match every host on a subnet), someone could try to exploit this capability by naming a host 198.51.100.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.

  If partial_revokes is ON, MySQL treats % and _ in grants as literal characters, and not as wildcards. Beginning with MySQL 8.0.35, use of these wildcards is deprecated (regardless of this variable's value), and you should expect this functionality to be removed in a future version of MySQL.

• 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. For example:

  CREATE USER 'david'@'198.51.100.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 = 198.51.100.0

  IP addresses that satisfy this condition range from 198.51.100.0 to 198.51.100.255.

  A netmask typically begins with bits set to 1, followed by bits set to 0. Examples:

  • 198.0.0.0/255.0.0.0: Any host on the 198 class A network

  • 198.51.0.0/255.255.0.0: Any host on the 198.51 class B network

  • 198.51.100.0/255.255.255.0: Any host on the 198.51.100 class C network

  • 198.51.100.1: Only the host with this specific IP address

• As of MySQL 8.0.23, a host value specified as an IPv4 address can be written using CIDR notation, such as 198.51.100.44/24.

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 198.51.100.2, that matches an account host value of 198.51.100.2 but not 198.051.100.2. Similarly, it matches an account host pattern like 198.51.100.% but not 198.051.100.%.

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.