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. Le rôle se réfère à un rôle ou à un rôle de base de données.

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 Aperçu du contrôle d’accès.

Cette commande est une variation de GRANT <privilèges>.

Voir aussi :

REVOKE <privilèges>

Syntaxe

-- Role
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 <role_name>
   [ { REVOKE | COPY } CURRENT GRANTS ]

-- Database role
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 DATABASE ROLE <database_role_name>
   [ { REVOKE | COPY } CURRENT GRANTS ]
Copy

Paramètres requis

object_name

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

object_type

Spécifie le type d’objet.

  • AGGREGATION POLICY

  • ALERT

  • AUTHENTICATION POLICY

  • COMPUTE POOL

  • DATABASE

  • DATABASE ROLE

  • DYNAMIC TABLE

  • EVENT TABLE

  • EXTERNAL TABLE

  • EXTERNAL VOLUME

  • FAILOVER GROUP

  • FILE FORMAT

  • FUNCTION

  • HYBRID TABLE

  • ICEBERG TABLE

  • IMAGE REPOSITORY

  • INTEGRATION

  • MATERIALIZED VIEW

  • NETWORK POLICY

  • NETWORK RULE

  • PACKAGES POLICY

  • PIPE

  • PROCEDURE

  • MASKING POLICY

  • PASSWORD POLICY

  • PROJECTION POLICY

  • REPLICATION GROUP

  • ROLE

  • ROW ACCESS POLICY

  • SCHEMA

  • SESSION POLICY

  • SECRET

  • SEQUENCE

  • STAGE

  • STREAM

  • TABLE

  • TAG

  • TASK

  • USER

  • VIEW

  • WAREHOUSE

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.

role_name

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

database_role_name

L’identificateur du rôle de base de données auquel la propriété de l’objet est transférée. Si l’identificateur n’est pas complet (sous la forme de db_name.database_role_name), la commande recherche le rôle de base de données dans la base de données actuelle de la session.

La propriété est limitée aux objets de la base de données qui contient le rôle de base de données.

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 <privilèges> 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

  • Vous ne pouvez pas transférer le privilège OWNERSHIP pour les objets suivants :

    • APPLICATION ROLE

    • CONNECTION

      Seul le rôle ACCOUNTADMIN peut avoir le privilège OWNERSHIP sur un objet de connexion.

    • SERVICE

    • SHARE

  • 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 ).

    Snowflake empêche l’exécution de la commande GRANT OWNERSHIP … REVOKE CURRENT GRANTS sur une base de données partagée. Pour plus de détails, consultez l’exemple de Base de données partagée dans cette rubrique.

  • 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. Les tâches transférées au même rôle à l’aide de l’option COPY CURRENT GRANTS sont également suspendues automatiquement.

  • 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.

  • Vous ne pouvez pas transférer le privilège OWNERSHIP sur un partage, ni le privilège OWNERSHIP sur une connexion. Seul le rôle ACCOUNTADMIN peut être propriétaire de la connexion.

  • Pour accorder le privilège OWNERSHIP sur des tables dynamiques, il faut s’assurer que le rôle récepteur dispose du privilège USAGE sur la base de données et le schéma qui contient la table dynamique, ainsi que sur l’entrepôt utilisé pour actualiser la table. Dans le cas contraire, les actualisations programmées ultérieures échouent.

  • Pour accorder le privilège OWNERSHIP aux futures tables dynamiques :

    • Si la table dynamique est définie pour s’initialiser à la création (c’est-à-dire INITIALIZE = ON_CREATE), assurez-vous que le nouveau rôle a des privilèges suffisants sur les objets référencés. Dans le cas contraire, l’actualisation initiale échoue et génère une erreur indiquant que l’objet est introuvable.

    • Si la table dynamique est définie pour s’initialiser à la date prévue (c’est-à-dire INITIALIZE = ON_SCHEDULE), assurez-vous que le nouveau rôle dispose de privilèges suffisants sur les objets référencés. Dans le cas contraire, les actualisations programmées ultérieures échouent.

  • Rôles de base de données :

    La propriété ne peut être transférée que sur les objets de la même base de données que le rôle de base de données.

  • Le transfert de propriété d’une table externe ou de sa base de données parente bloque l’actualisation automatique des métadonnées de table en définissant la propriété AUTO_REFRESH sur FALSE. Pour réinitialiser la propriété après un transfert de propriété, utilisez la commande ALTER EXTERNAL TABLE.

Exemples

Rôles

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;
Copy

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;
Copy

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;
Copy

Rôles de base de données

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

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

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

GRANT OWNERSHIP ON TABLE mydb.public.mytable
  TO ROLE mydb.dr1
  COPY CURRENT GRANTS;
Copy

Base de données partagée

Pour transférer le privilège OWNERSHIP sur une base de données partagée, utilisez ces commandes :

REVOKE USAGE ON DATABASE mydb FROM SHARE myshare;
GRANT OWNERSHIP ON DATABASE mydb TO ROLE r2;
GRANT USAGE ON DATABASE mydb TO ROLE r2;
Copy

Si nécessaire, réaccordez la base de données au partage à l’aide d’une commande GRANT <privilège> … TO SHARE.