Catégories :

Utilisateur et sécurité DDL (contrôle d’accès)

GRANT OWNERSHIP

Transfère la propriété d’un objet (ou de tous les objets d’un type spécifié dans un schéma) d’un rôle à un autre. OWNERSHIP est un type de privilège spécial qui ne peut être accordé que d’un rôle à un autre ; il ne peut être révoqué. Pour plus de détails, voir Contrôle d’accès dans Snowflake.

Cette commande est une variation de GRANT <privileges> … TO ROLE.

Voir aussi :

REVOKE <privileges> … FROM ROLE

Syntaxe

GRANT OWNERSHIP
   { ON { <object_type> <object_name> | ALL <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> } }
   | ON FUTURE <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> }
   }
   TO ROLE <name>
   [ { REVOKE | COPY } CURRENT GRANTS ]

Où :

objectType ::=
  { ROLE | USER | WAREHOUSE | INTEGRATION | NETWORK POLICY | SESSION POLICY | DATABASE | SCHEMA | TABLE | VIEW | STAGE | FILE FORMAT | STREAM | TASK | MASKING POLICY | ROW ACCESS POLICY | TAG | PIPE | FUNCTION | PROCEDURE | SEQUENCE }

Paramètres requis

object_name

Spécifie l’identificateur de l’objet sur lequel vous transférez la propriété.

object_type

Indique le type d’objet (pour les objets de schéma) :

TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW | MASKING POLICY | ROW ACCESS POLICY | SESSION POLICY | SEQUENCE | FUNCTION | PROCEDURE | FILE FORMAT | STAGE | PIPE | STREAM | TASK

object_type_plural

Forme plurielle de object_type (par exemple, TABLES, VIEWS).

Notez que les autorisations globales sur les canaux ne sont pas autorisées.

name

L’identificateur du rôle auquel la propriété de l’objet est transférée.

Paramètres facultatifs

[ REVOKE | COPY ] CURRENT GRANTS

Indique s’il faut supprimer ou transférer tous les privilèges sortants existants sur l’objet lorsque la propriété est transférée à un nouveau rôle :

Note

Les privilèges sortants font référence à tous les privilèges accordés sur l’objet individuel dont la propriété change.

Lors du transfert de propriété d’un rôle, les autorisations actuelles font référence à tous les rôles qui ont été accordés au rôle actuel (pour créer une hiérarchie de rôles). Si la propriété d’un rôle est transférée avec les autorisations actuelles copiées, alors la sortie de la commande SHOW GRANTS montre le nouveau propriétaire comme le concédant de tous les rôles enfants du rôle actuel.

REVOKE

Exécute la sémantique RESTRICT, qui exige la suppression de tous les privilèges sortants d’un objet avant de transférer la propriété à un nouveau rôle. Ceci évite au nouveau rôle de propriétaire d’hériter sans le savoir de l’objet avec des privilèges déjà accordés.

Après le transfert de propriété, les privilèges pour l’objet doivent être explicitement accordés de nouveau sur le rôle.

Notez que le mot-clé REVOKE ne fonctionne pas lorsque vous accordez à un rôle la propriété de futurs objets d’un type spécifié dans une base de données ou un schéma (en utilisant GRANT OWNERSHIP ON FUTURE <type_objet>).

COPY

Transfère la propriété d’un objet ainsi qu’une copie de tout privilège sortant existant sur l’objet. Après le transfert, le nouveau propriétaire est identifié dans le système comme le concédant des privilèges de sortie copiés (c’est-à-dire que dans la sortie SHOW GRANTS de l’objet, le nouveau propriétaire est répertorié dans la colonne GRANTED_BY pour tous les privilèges). Par conséquent, tous les privilèges qui ont été réattribués par la suite avant le changement de propriété ne dépendent plus du rôle initial du concédant.

Révoquer un privilège en utilisant REVOKE <privileges> … FROM ROLE avec l’option CASCADE ne révoque pas récursivement les privilèges associés existants. Les autorisations doivent être explicitement révoquées.

Ce paramètre exige que le rôle qui exécute la commande GRANT OWNERSHIP ait le privilège MANAGE GRANTS sur le compte.

La valeur par défaut est : aucun. Aucune des deux opérations n’est effectuée sur les privilèges sortants existants.

Note

Une instruction GRANT OWNERSHIP échoue si les privilèges sortants existants sur l’objet ne sont ni révoqués ni copiés.

Notes sur l’utilisation

  • Un rôle qui possède le privilège MANAGE GRANTS peut transférer la propriété d’un objet à n’importe quel rôle ; en revanche, un rôle qui n’a pas le privilège MANAGE GRANTS peut seulement transférer la propriété de lui-même à un rôle enfant dans la hiérarchie des rôles.

  • L’instruction GRANT OWNERSHIP est bloquée si des privilèges sortants (c’est-à-dire dépendants) existent sur l’objet. Le propriétaire de l’objet (ou un rôle supérieur) peut explicitement copier tous les privilèges actuels dans le nouveau rôle de propriétaire (en utilisant l’option COPY CURRENT GRANTS) ou révoquer tous les privilèges sortants sur l’objet avant le transfert de propriété (en utilisant l’option REVOKE CURRENT GRANTS ).

  • Le transfert de propriété n’affecte que les objets existants au moment où la commande est émise. Tous les objets créés après l’émission de la commande sont la propriété du rôle utilisé au moment de la création de l’objet.

  • Le transfert de propriété des objets des types suivants est bloqué, sauf si des conditions supplémentaires sont remplies :

    Canaux

    Le canal doit être mis en pause.

    Tâches

    La tâche planifiée (c’est-à-dire la tâche autonome ou la tâche racine dans une arborescence) doit être suspendue. Notez que toutes les tâches du conteneur sont suspendues automatiquement si toutes les tâches d’une base de données ou d’un schéma spécifié sont transférées à un autre rôle.

  • Lorsque les autorisations futures sur le même type d’objet sont définies à la fois au niveau de la base de données et du schéma, les autorisations au niveau du schéma ont priorité sur les autorisations au niveau de la base de données et les autorisations au niveau de la base de données sont ignorées.

  • Pour accorder la propriété sur une vue matérialisée, utilisez GRANT OWNERSHIP ON VIEW.... Il n’y a pas d’instruction GRANT OWNERSHIP ON MATERIALIZED VIEW distincte.

Exemples

Révoquer tous les privilèges sortants sur la base de données mydb, qui appartient actuellement au rôle manager, avant de transférer la propriété au rôle analyst :

REVOKE ALL PRIVILEGES ON DATABASE mydb FROM ROLE manager;

GRANT OWNERSHIP ON DATABASE mydb TO ROLE analyst;

GRANT ALL PRIVILEGES ON DATABASE mydb TO ROLE analyst;

Notez que cet exemple illustre le processus par défaut (et recommandé) de transfert de propriété en plusieurs étapes.

En une seule étape, révoquer tous les privilèges des tables existantes dans le schéma mydb.public et transférer la propriété des tables (ainsi qu’une copie de leurs privilèges actuels) au rôle analyst :

GRANT OWNERSHIP ON ALL TABLES IN SCHEMA mydb.public TO ROLE analyst COPY CURRENT GRANTS;

Accorder la propriété sur la table mydb.public.mytable au rôle analyst ainsi qu’une copie de tous les privilèges sortants courants sur la table :

GRANT OWNERSHIP ON TABLE mydb.public.mytable TO ROLE analyst COPY CURRENT GRANTS;
Revenir au début