Rechercher dans le manuel MySQL
22.5.12.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. If you wish, you can enable automatic distribution of
MySQL users and privileges across NDB Cluster SQL nodes; see
Section 22.5.16, “Distributed MySQL Privileges (Not Supported)”, 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=
and access this NDB Cluster. Using the MySQL
management_host
root
account, this person can then perform
the following actions:
Execute metadata statements such as
SHOW DATABASES
statement (to obtain a list of allNDB
databases on the server) orSHOW TABLES FROM
statement to obtain a list of allsome_ndb_database
NDB
tables in a given databaseRun any legal MySQL statements on any of the discovered tables, such as:
SELECT * FROM
to read all the data from any tablesome_table
DELETE FROM
to delete all the data from a tablesome_table
DESCRIBE
orsome_table
SHOW CREATE TABLE
to determine the table schemasome_table
UPDATE
to fill a table column with “garbage” data; this could actually cause much greater damage than simply deleting all the datasome_table
SETcolumn1
=some_value
More insidious variations might include statements like these:
or
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 theINFORMATION_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 inINFORMATION_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.
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.
If you wish to employ NDB Cluster's distributed privilege
capabilities, you should not simply convert the system tables in
the mysql
database to use the
NDB
storage engine manually. Use
the stored procedure provided for this purpose instead; see
Section 22.5.16, “Distributed MySQL Privileges (Not Supported)”.
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.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-mysql-cluster-security-mysql-privileges.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.