7.11.2 NDB Cluster and MySQL Privileges

In this section, we discuss how the MySQL privilege system works
in relation to NDB Cluster and the implications of this for
keeping an NDB Cluster secure.

Standard MySQL privileges apply to NDB 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. The same thing is true with respect to the
CREATE USER and
DROP USER statements.

It is important to keep in mind that, by default, the MySQL
grant tables use the MyISAM storage
engine. Because of this, those tables are not normally
duplicated or shared among MySQL servers acting as SQL nodes in
an NDB Cluster. In other words, changes in users and their
privileges do not automatically propagate between SQL nodes by
default. In NDB Cluster 7.2 (and later), you can enable
automatic distribution of MySQL users and privileges across NDB
Cluster SQL nodes; see
Section 7.15, “Distributed MySQL Privileges for NDB Cluster”, for
details.

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; (This is true
even if you are not using automatic distribution of user
privileges. The definitive 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 NDB
Cluster management server performs no checking of the host
from which a MySQL Server (or other API node) accesses the
NDB Cluster.

There is no firewall, or the firewall fails to protect
against access to the NDB Cluster from hosts external to the
network.

The host name or IP address of the NDB Cluster 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=management_host
and access this NDB Cluster. Using the MySQL
root account, this person can then perform
the following actions:

Run any legal MySQL statements on any of the discovered
tables, such as:

SELECT * FROM
some_table to read
all the data from any table

DELETE FROM
some_table to
delete all the data from a table

DESCRIBE
some_table or
SHOW CREATE TABLE
some_table to
determine the table schema

UPDATE some_table
SET column1 =
some_value to fill
a table column with “garbage” data; this
could actually cause much greater damage than simply
deleting all the data

More insidious variations might include statements like
these:

UPDATE some_table SET an_int_column = an_int_column + 1

or

UPDATE some_table SET a_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 NDB
Cluster SQL nodes unless you are using distributed
privileges.

In sum, you cannot have a safe NDB Cluster if it is directly
accessible from outside your local network.

Important

Never leave the MySQL root account password
empty. This is just as true when running MySQL as
an NDB 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 an NDB Cluster.

Prior to NDB Cluster 7.2, 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. Beginning with NDB Cluster 7.2,
you can use a stored procedure provided for this purpose (see
Section 7.15, “Distributed MySQL Privileges for NDB Cluster”), but you
are strongly advised not to attempt convert the system tables
manually.

Otherwise, 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 most important points to remember regarding the MySQL
privilege system with regard to NDB Cluster are listed here:

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.

You can distribute MySQL users and privileges among SQL
nodes using the SQL script, and the stored procedures it
contains, that are supplied for this purpose in the NDB
Cluster distribution.

Once a MySQL user is granted privileges on an
NDB table from one SQL node in
an NDB Cluster, that user can “see” any data in
that table regardless of the SQL node from which the data
originated, even if you are not using privilege
distribution.