Oracle 5.0 Reference Manual page 1709

17.5.10.2. MySQL Cluster and MySQL Privileges
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 [578]
database, table, and column level. As with any other MySQL Server, user and privilege information is
stored in the
tables, databases containing such tables, and columns within such tables are identical in all respects
with the
GRANT
MySQL storage engine. The same thing is true with respect to the
statements.
It is important to keep in mind that the MySQL grant tables use the
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
execute an SQL statement on server A that creates a new user
the
SELECT
mysql> GRANT SELECT ON mydb.mytable
-> TO jon@localhost IDENTIFIED BY 'mypass';
This user is not created on server B. 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
one SQL node from users that have privileges on another SQL node. The most far-reaching example of
this is the MySQL
with empty
[mysqld]
dangerous. To understand why, consider the following scenario:
• The
config.ini
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
--ndb-connectstring=management_host
account, this person can then perform the following actions:
• Execute a
• Execute a
given database
• Run any legal MySQL statements on any of those tables, such as:
MySQL Cluster Security Issues
extremely insecure means of managing the cluster, and is almost certain to be
compromised sooner or later.
privilege, [578]
UPDATE
system database. The SQL statements used to grant and revoke privileges on
mysql
and statements used in connection with database objects involving any (other)
REVOKE
table named
NDB
[578] privilege on that table:
account, which can perform any action on any database object. In combination
root
or sections of the
[api]
file contains at least one empty
statement to obtain a list of all databases that exist in the cluster
SHOW DATABASES
SHOW TABLES FROM some_database
privilege, [577]
DELETE
in a database named mydb, and that you
mytable
config.ini
[mysqld]
and access the Cluster. Using the MySQL
statement to obtain a list of all
1689
privilege, and so on) granted on the
and
CREATE USER
storage engine. Because
MyISAM
and grants this user
jon@localhost
file, this account can be especially
or section. This means that the
[api]
--ndbcluster
NDB
NDB
DROP USER
tables on
NDB
root
tables in a