Access Control, Stage 1: Connection Verification
585
IP addresses that satisfy this condition and can connect to the MySQL server are those in the range
from
192.58.197.0
to
192.58.197.255
.
The netmask can only be used to tell the server to use 8, 16, 24, or 32 bits of the address. 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 following netmask will not work because it masks 28 bits, and 28 is not a multiple of 8:
192.168.0.1/255.255.255.240
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, this comparison is performed 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.
But 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 this, it is advisable to check the format in which your DNS returns host names
and addresses, and use values in the same format in MySQL account names.
6.2.4. Access Control, Stage 1: Connection Verification
When you attempt to connect to a MySQL server, the server accepts or rejects the connection based
on your identity and whether you can verify your identity by supplying the correct password. If not, the
server denies access to you completely. Otherwise, the server accepts the connection, and then enters
Stage 2 and waits for requests.
Your identity is based on two pieces of information:
• The client host from which you connect
• Your MySQL user name
Identity checking is performed using the three
user
table scope columns (
Host
,
User
, and
Password
). The server accepts the connection only if the
Host
and
User
columns in some
user
table row match the client host name and user name and the client supplies the password specified
in that row. The rules for permissible
Host
and
User
values are given in
Section 6.2.3, “Specifying
Account Names”
.
If the
User
column value is nonblank, the user name in an incoming connection must match exactly.
If the
User
value is blank, it matches any user name. If the
user
table row that matches an incoming
connection has a blank user name, the user is considered to be an anonymous user with no name, not
a user with the name that the client actually specified. This means that a blank user name is used for
all further access checking for the duration of the connection (that is, during Stage 2).
The
Password
column can be blank. This is not a wildcard and does not mean that any password
matches. It means that the user must connect without specifying a password.
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...