In this section, we discuss how the MySQL privilege system works in relation to MySQL Cluster and the implications of this for keeping a MySQL Cluster secure.
Standard MySQL privileges apply to MySQL Cluster tables. This
includes all MySQL privilege types
(SELECT
privilege,
UPDATE
privilege,
DELETE
privilege, and so on)
granted on the database, table, and column level. As with any
other MySQL Server, user and privilege information is stored in
the mysql
system database. The SQL statements
used to grant and revoke privileges on
NDB
tables, databases containing
such tables, and columns within such tables are identical in all
respects with the GRANT
and
REVOKE
statements used in
connection with database objects involving any (other) MySQL
storage engine.
It is important to keep in mind that the MySQL grant tables use
the MyISAM
storage engine. Because of this,
those tables are not duplicated or shared among MySQL servers
acting as SQL nodes in a MySQL Cluster. By way of example,
suppose that two SQL nodes A
and B are connected to the same
MySQL Cluster, which has an NDB
table named mytable
in a database named
mydb
, and that you execute an SQL statement
on server A that creates a new
user jon@localhost
and grants this user the
SELECT
privilege on that table:
mysql>GRANT SELECT ON mydb.mytable
->TO jon@localhost IDENTIFIED BY 'mypass';
This user is not created on server B. In order for this to take place, the statement must also be run on server B. Similarly, statements run on server A and affecting the privileges of existing users on server A do not affect users on server B unless those statements are actually run on server B as well.
In other words, changes in users and their privileges do not automatically propagate between SQL nodes. Synchronization of privileges between SQL nodes must be done either manually or by scripting an application that periodically synchronizes the privilege tables on all SQL nodes in the cluster.
Conversely, because there is no way in MySQL to deny privileges
(privileges can either be revoked or not granted in the first
place, but not denied as such), there is no special protection
for NDB
tables on one SQL node from
users that have privileges on another SQL node. The most
far-reaching example of this is the MySQL
root
account, which can perform any action on
any database object. In combination with empty
[mysqld]
or [api]
sections
of the config.ini
file, this account can be
especially dangerous. To understand why, consider the following
scenario:
The config.ini
file contains at least
one empty [mysqld]
or
[api]
section. This means that the
Cluster management server performs no checking of the host
from which a MySQL Server (or other API node) accesses the
MySQL Cluster.
There is no firewall, or the firewall fails to protect against access to the Cluster from hosts external to the network.
The host name or IP address of the Cluster's management server is known or can be determined from outside the network.
If these conditions are true, then anyone, anywhere can start a
MySQL Server with --ndbcluster
--ndb-connectstring=
and access the Cluster. Using the MySQL management_host
root
account, this person can then perform the following actions:
Execute a SHOW DATABASES
statement to obtain a list of all databases that exist in
the cluster
Execute a SHOW TABLES FROM
statement to obtain a list of all
some_database
NDB
tables in a given
database
Run any legal MySQL statements on any of those tables, such as:
SELECT * FROM
to
read all the data from any table
some_table
DELETE FROM
to
delete all the data from a table
some_table
DESCRIBE
or
some_table
SHOW CREATE TABLE
to
determine the table schema
some_table
UPDATE
to
fill a table column with “garbage”
data; this could actually cause much greater damage
than simply deleting all the data
some_table
SET
column1
=
any_value1
Even more insidious variations might include statements like these:
UPDATEsome_table
SETan_int_column
=an_int_column
+ 1
or
UPDATEsome_table
SETa_varchar_column
= REVERSE(a_varchar_column
)
Such malicious statements are limited only by the imagination of the attacker.
The only tables that would be safe from this sort of
mayhem would be those tables that were created using
storage engines other than
NDB
, and so not visible to a
“rogue” SQL node.
A user who can log in as root
can
also access the INFORMATION_SCHEMA
database and its tables, and so obtain information about
databases, tables, stored routines, scheduled events,
and any other database objects for which metadata is
stored in INFORMATION_SCHEMA
.
It is also a very good idea to use different passwords for
the root
accounts on different cluster
SQL nodes.
In sum, you cannot have a safe MySQL Cluster if it is directly accessible from outside your local network.
Never leave the MySQL root account password empty. This is just as true when running MySQL as a MySQL Cluster SQL node as it is when running it as a standalone (non-Cluster) MySQL Server, and should be done as part of the MySQL installation process before configuring the MySQL Server as an SQL node in a MySQL Cluster.
You should never convert the system tables in the
mysql
database to use the
NDB
storage engine. There are a
number of reasons why you should not do this, but the most
important reason is this: Many of the SQL statements
that affect mysql
tables storing information
about user privileges, stored routines, scheduled events, and
other database objects cease to function if these tables are
changed to use any storage engine other than
MyISAM
. This is a consequence of
various MySQL Server internals which are not expected to change
in the foreseeable future.
If you need to synchronize mysql
system
tables between SQL nodes, you can use standard MySQL replication
to do so, or employ a script to copy table entries between the
MySQL servers.
Summary. The two most important points to remember regarding the MySQL privilege system with regard to MySQL Cluster are:
Users and privileges established on one SQL node do not automatically exist or take effect on other SQL nodes in the cluster.
Conversely, removing a user or privilege on one SQL node in the cluster does not remove the user or privilege from any other SQL nodes.
Once a MySQL user is granted privileges on an
NDB
table from one SQL node
in a MySQL Cluster, that user can “see” any
data in that table regardless of the SQL node from which
the data originated.
User Comments
Add your own comment.