NDB Cluster Security Issues 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. If you wish, you can enable automatic distribution of MySQL users and privileges across NDB Cluster SQL nodes; see Section 23.5.12, “Distributed MySQL Privileges with NDB_STORED_USER” , 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. •Execute metadata statements such as  SHOW DATABASES  statement (to obtain a list of all  NDB databases on the server) or  SHOW TABLES FROM  some_ndb_database  statement to obtain a list of all  NDB  tables in a given database 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: More insidious variations might include statements like these: • 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 4606