> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Paramètres des permissions pour les requêtes.

# Permissions pour les requêtes

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`](/fr/reference/statements/delete), [`UPDATE`](/fr/reference/statements/update), `ALTER TABLE ... DELETE`, `ALTER TABLE ... UPDATE`.
3. Requêtes de modification des paramètres : `SET`, `USE`.
4. Requêtes [DDL](https://en.wikipedia.org/wiki/Data_definition_language) : `CREATE`, `ALTER`, `RENAME`, `EXCHANGE`, `ATTACH`, `DETACH`, `DROP`, `TRUNCATE`.
5. Requêtes de gestion des accès : [`GRANT`](/fr/reference/statements/grant), [`REVOKE`](/fr/reference/statements/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](/fr/concepts/features/security/access-rights).
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 :

<h2 id="readonly">
  readonly
</h2>

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](/fr/reference/settings/session-settings/other#readonly) ; 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.

<Note>
  Via l'[interface HTTP](/fr/concepts/features/interfaces/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](/fr/reference/statements/create/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](/fr/concepts/features/configuration/settings/constraints-on-settings), qui recommande
  également de ne pas rendre le paramètre `readonly` lui-même
  [modifiable en mode lecture seule](/fr/concepts/features/configuration/settings/constraints-on-settings#readonly-changeable-in-readonly).
</Note>

<h2 id="allow_ddl">
  allow\_ddl
</h2>

Autorise ou interdit les requêtes [DDL](https://en.wikipedia.org/wiki/Data_definition_language) 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

<Note>
  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`.
</Note>

<Info>
  **KILL QUERY**

  Interrompre 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.
</Info>

<h2 id="other-relevant-settings">
  Autres paramètres pertinents
</h2>

* [`allow_introspection_functions`](/fr/reference/settings/session-settings/allow#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`](/fr/reference/settings/session-settings/allow#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.