Skip to main content
Les requêtes dans ClickHouse peuvent être réparties en plusieurs types :
  1. Requêtes de lecture de données : SELECT, SHOW, DESCRIBE, EXISTS.
  2. Requêtes d’écriture de données : INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE.
  3. Requêtes de modification des paramètres : SET, USE.
  4. Requêtes DDL : CREATE, ALTER, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE.
  5. Requêtes de gestion des accès : GRANT, REVOKE, ainsi que CREATE, ALTER et DROP d’utilisateurs, de rôles, de politiques de lignes, de politiques de masquage, de quotas et de settings profiles. Voir contrôle d’accès et gestion des comptes.
  6. KILL QUERY.
ALTER TABLE ... DELETE et ALTER TABLE ... UPDATE modifient les données et non les métadonnées de la table, d’où leur présence ci-dessus parmi les requêtes d’écriture de données. Elles requièrent les privilèges ALTER DELETE et ALTER UPDATE, qui sont également ceux exigés par les instructions autonomes DELETE et UPDATE. Ces privilèges appartiennent au groupe de privilèges ALTER TABLE : allow_ddl = 0 rejette donc ces quatre instructions sur une table persistante. Les paramètres suivants définissent les permissions utilisateur selon le type de requête :

​
readonly

Restreint les requêtes qu’une session peut exécuter. Les valeurs de ce paramètre, sa valeur par défaut et les paramètres que chaque valeur permet de modifier sont décrits dans la référence des paramètres ; cette section décrit les catégories de requêtes autorisées par chaque valeur. Avec la valeur 1, les requêtes suivantes sont autorisées :
  • Les requêtes de lecture (comme SELECT et les requêtes équivalentes).
  • Les requêtes qui ne modifient que le contexte de session (comme USE).
Avec la valeur 2, s’ajoutent aux précédentes SET, CREATE TEMPORARY TABLE et RESTORE. Un RESTORE peut créer une table et y charger des données : readonly = 2 n’empêche donc pas à lui seul une session d’écrire, alors que readonly = 1 le refuse. BACKUP n’est restreint par readonly pour aucune valeur : une session disposant des privilèges nécessaires pour sauvegarder une table peut écrire une sauvegarde même avec readonly = 1. Ne comptez pas sur readonly pour empêcher les sauvegardes. La plupart des fonctions de table nécessitent le privilège CREATE TEMPORARY TABLE : un SELECT qui lit depuis l’une d’elles est refusé avec readonly = 1, mais pas avec readonly = 2. Certaines, comme numbers, sont autorisées en mode read-only. Pour toute valeur supérieure à 0, aucune des opérations suivantes n’est permise sur une table persistante : les requêtes d’écriture de données (INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE) ni les requêtes DDL (CREATE, ALTER TABLE, ALTER VIEW, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE TABLE). Les instructions SYSTEM qui requièrent un privilège du groupe SYSTEM, ainsi que les opérations CREATE, ALTER et DROP sur les utilisateurs, les rôles, les politiques de ligne, les politiques de masquage, les quotas et les settings profiles ne sont pas permises non plus. La gestion des named collections fait exception : readonly ne restreint ni CREATE NAMED COLLECTION, ni ALTER NAMED COLLECTION, ni DROP NAMED COLLECTION. L’octroi d’un privilège avec GRANT est également refusé, mais ce n’est pas le cas de toutes les instructions de gestion des accès : un REVOKE local et GRANT CURRENT GRANTS ne sont pas soumis à readonly, de sorte qu’une session en lecture seule peut encore révoquer un privilège qu’elle détient avec l’option grant et propager ses propres grants à un autre utilisateur. La révocation d’un privilège ON CLUSTER, elle, est refusée. Les temporary tables échappent à ces deux paramètres : une session autorisée à en créer une peut aussi exécuter ALTER dessus, y insérer des données et la supprimer.
Via l’interface HTTP, une requête dont la méthode n’est pas POST s’exécute avec readonly = 2 si la valeur effective serait sinon 0. Une valeur plus stricte déjà définie par les paramètres de l’utilisateur ou par un settings profile est conservée. PUT et DELETE font exception lorsqu’ils atteignent un handler défini en SQL qui les accepte ; une telle requête peut donc modifier des données lorsque la valeur effective de readonly est 0. Sinon, utilisez la méthode POST pour modifier des données.Sur une requête ainsi élevée, un paramètre readonly présent dans la query string est refusé avec le message Cannot modify 'readonly' setting in readonly mode, sauf s’il désigne la valeur que la requête possède déjà.Il existe un moyen d’interdire à l’utilisateur de modifier uniquement certains paramètres, et un moyen d’autoriser la modification de certains paramètres seulement sous les restrictions de readonly = 1. Pour plus de détails, voir constraints on settings, qui recommande également de ne pas rendre le paramètre readonly lui-même modifiable en mode lecture seule.

​
allow_ddl

Autorise ou interdit les requêtes DDL sur les bases de données, les tables, les vues, les dictionnaires, les fonctions définies par l’utilisateur, les workloads, les resources et les handlers définis en SQL. Valeurs possibles :
  • 0 — L’exécution d’une requête sur un objet persistant nécessitant l’un des privilèges suivants est bloquée : CREATE DATABASE, DROP DATABASE, CREATE TABLE, CREATE VIEW, ALTER TABLE, ALTER VIEW, DROP TABLE, DROP VIEW, TRUNCATE, CREATE DICTIONARY, DROP DICTIONARY, CREATE FUNCTION, DROP FUNCTION, CREATE WORKLOAD, DROP WORKLOAD, CREATE RESOURCE, DROP RESOURCE, CREATE HANDLER, ALTER HANDLER, DROP HANDLER. RENAME, EXCHANGE, ATTACH et DETACH requièrent également ces privilèges et sont donc bloqués eux aussi, à ceci près que ALTER TABLE ... ATTACH PARTITION et ATTACH PART ne nécessitent que INSERT et ne sont pas bloqués par ce paramètre, bien que readonly les bloque sur une table persistante. ATTACH PARTITION ... FROM requiert en outre ALTER DELETE et est donc bloqué. L’octroi et la révocation de ces privilèges ne sont pas bloqués.
  • 1 — Ce paramètre ne bloque rien.
Valeur par défaut : 1
Vous ne pouvez pas exécuter SET allow_ddl = 1 si allow_ddl = 0 pour la session en cours.allow_ddl ne restreint pas les requêtes de gestion des accès : GRANT, REVOKE ainsi que CREATE, ALTER et DROP d’utilisateurs, de rôles, de politiques de ligne, de politiques de masquage, de quotas et de settings profiles n’en sont pas affectés. CREATE TEMPORARY TABLE et la gestion des named collections n’en sont pas affectés non plus, pas plus que ALTER DATABASE ... MODIFY SETTING, ALTER DATABASE ... MODIFY COMMENT et UNDROP TABLE, que readonly ne restreint pas non plus. Au sein d’un CREATE ou d’un ALTER portant sur un utilisateur, un rôle ou un settings profile, une clause SETTINGS allow_ddl = 1 est refusée tant que la session en cours a allow_ddl = 0, tandis qu’une clause SETTINGS allow_ddl = 0 est acceptée. Un paramètre intégré est vérifié au regard des contraintes de paramètres propres à la session, ce qui explique également le refus de SET allow_ddl = 1.
KILL QUERYInterrompre vos propres requêtes ne nécessite pas le privilège KILL QUERY ; cela fonctionne donc avec n’importe quelle combinaison de readonly et d’allow_ddl. En revanche, le privilège SELECT sur system.processes est requis, sauf pour KILL QUERY WHERE query_id = '<id>', qui annule votre propre requête portant cet identifiant sans lire cette table. Interrompre une requête appartenant à un autre utilisateur, ainsi que tout KILL QUERY ... ON CLUSTER, exigent le privilège KILL QUERY, que readonly = 1 et readonly = 2 refusent.

​
Autres paramètres pertinents

  • allow_introspection_functions est le troisième paramètre qui intervient dans la décision d’autorisation elle-même, aux côtés de readonly et allow_ddl. Lorsqu’il est désactivé, l’exécution d’une fonction d’introspection est bloquée. En revanche, l’octroi du privilège INTROSPECTION ne l’est pas.
  • allow_non_metadata_alters n’est pas un paramètre d’autorisation, mais il restreint davantage ALTER TABLE : lorsqu’il est désactivé, une commande modifiant la définition de table est refusée sur les tables de la famille MergeTree si son application entraînait une réécriture des données sur disque (DROP COLUMN, RENAME COLUMN, un changement de type MODIFY COLUMN, MODIFY TTL). CLEAR COLUMN, CLEAR INDEX et CLEAR PROJECTION sont également refusées, bien qu’elles laissent la définition inchangée. Les instructions qui constituent elles-mêmes des mutations, telles que ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE et ALTER TABLE ... MATERIALIZE INDEX, ne sont pas concernées.
Dernière modification le 26 septembre 2026