GRANT OWNERSHIP¶

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 ]

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¶