Restriction des droits de l’appelant¶

Un exécutable tel qu’une procédure stockée ou un service de Snowpark Container Services peut s’exécuter avec les privilèges du propriétaire de l’exécutable (droits du propriétaire) ou de l’appelant de l’exécutable (droits de l’appelant). Si un exécutable s’exécute avec les droits de l’appelant, l’exécutable ne peut effectuer une performance que si l’appelant dispose de privilèges lui permettant d’effectuer cette action en dehors du contexte de l’exécutable.

La restriction des droits de l’appelant permet à un exécutable de s’exécuter avec les droits de l’appelant, mais restreint les privilèges de l’appelant avec lesquels l’exécutable s’exécute. Avec des droits d’appelants restreints, un exécutable ne peut pas s’exécuter avec un privilège spécifique à moins qu’un administrateur ne l’autorise expressément.

À propos des autorisations accordées aux appelants¶

Les administrateurs utilisent les autorisations de l’appelant pour définir les privilèges de l’appelant avec lesquels un exécutable peut s’exécuter. Par exemple, si un appelant dispose des privilèges SELECT et INSERT sur une table, mais qu’il n’existe pas d’autorisation de l’appelant permettant à l’exécutable de s’exécuter avec le privilège INSERT, l’exécutable dont les droits de l’appelant sont restreints ne peut pas s’exécuter avec le privilège INSERT lorsqu’il agit sur la table.

Une autorisation de l’appelant n’accorde aucun privilège mais restreint les privilèges existants de l’appelant qui sont utilisés lors de l’exécution de l’exécutable. Par exemple, si un appelant exécute une procédure stockée pour effectuer une sélection dans une table, l’appelant doit déjà disposer du privilège SELECT sur la table et que l’autorisation de l’appelant doit permettre à la procédure stockée de s’exécuter avec le privilège SELECT.

Les droits de l’appelant sont accordés par l’administrateur au rôle qui possède un exécutable. Les autorisations de l’appelant sont accordées aux objets tels que les tables et les entrepôts auxquels l’exécutable accède. Lorsque l’exécutable tente d’accéder aux objets, les autorisations de l’appelant associées au propriétaire de l’exécutable sont utilisés pour déterminer quels privilèges de l’appelant peuvent être utilisés pour l’opération.

Exécutables s’exécutant avec des droits d’appelants restreints¶

L’utilisateur qui crée un exécutable détermine si l’exécutable s’exécute avec les droits du propriétaire, les droits de l’appelant ou les droits restreints de l’appelant. S’ils choisissent les droits restreints de l’appelant, chaque privilège requis par l’exécutable doit être spécifié dans un ou plusieurs autorisations de l’appelant qui sont accordées au propriétaire de l’exécutable.

Pour une procédure stockée, le paramètre EXECUTE AS définit si la procédure s’exécute avec les droits du propriétaire, les droits de l’appelant ou les droits restreints de l’appelant. Voici un exemple de définition de la procédure à exécuter avec des droits restreints de l’appelant :

CREATE OR REPLACE PROCEDURE sp_pi()
  RETURNS FLOAT NOT NULL
  LANGUAGE JAVASCRIPT
  EXECUTE AS RESTRICTED CALLER
  AS
  $$
  RETURN 3.1415926;
  $$
  ;

Copy

Pour obtenir la liste des restrictions applicables aux exécutables qui s’exécutent avec des droits d’appelants restreints, consultez Limites d’un exécutable dont les droits de l’appelant sont restreints.

Accorder les autorisations de l’appelant¶

Les autorisations accordées à l’appelant sont accordées sur les objets tels que les tables et les bases de données auxquelles un exécutable accède. L’appelant se voit accorder le rôle ou le rôle de base de données qui possède l’exécutable.

L’instruction GRANT qu’un administrateur utilise pour accorder une autorisation à un appelant comporte différentes variantes, en fonction de la manière dont vous souhaitez accorder des droits à l’appelant. Les variations sont les suivantes :

GRANT CALLER — Accorde à l’appelant des autorisations sur un objet spécifique. Chaque autorisation de l’appelant créée par l’instruction permet à l’exécutable de s’exécuter avec un privilège spécifié.
GRANT ALL CALLER PRIVILEGES — Accorde à l’appelant des autorisations sur un objet spécifique. Les autorisations de l’appelant créées par l’instruction permettent à l’exécutable de s’exécuter avec tous les privilèges de l’appelant.
GRANT INHERITED CALLER — Accorde à l’appelant des autorisations sur tous les objets actuels et futurs du même type lorsqu’ils partagent un schéma, une base de données ou un compte commun. Chaque autorisation de l’appelant créée par l’instruction permet à l’exécutable de s’exécuter avec un privilège spécifié.
GRANT ALL INHERITED CALLER PRIVILEGES — Accorde à l’appelant des autorisations sur tous les objets actuels et futurs du même type lorsqu’ils partagent un schéma, une base de données ou un compte commun. Les autorisations de l’appelant créées par l’instruction permettent à l’exécutable de s’exécuter avec tous les privilèges de l’appelant.

Une seule instruction GRANT peut entraîner l’octroi de plusieurs autorisations de l’appelant au propriétaire de l’exécutable. Par exemple, GRANT CALLER INSERT, SELECT … donne lieu à deux autorisation de l’appelant, l’une pour le privilège INSERT et l’autre pour le privilège SELECT. De même, une instruction GRANT ALL INHERITED CALLER PRIVILEGES entraîne l’octroi par l’appelant de tous les privilèges pouvant être accordés sur le type d’objet spécifié.

Pour connaître la syntaxe complète, y compris les paramètres, de l’octroi d’une autorisation à l’appelant, voir GRANT CALLER.

Exemples¶

Les exemples suivants montrent comment un administrateur peut utiliser les autorisations de l’appelant pour contrôler les privilèges de l’appelant avec lesquels un exécutable peut s’exécuter.

Les exécutables appartenant à owner_role qui accèdent à une vue v1 peuvent être exécutés avec le privilège SELECT sur la vue :

GRANT CALLER SELECT ON VIEW v1 TO owner_role;

Copy

Les exécutables appartenant à owner_role qui accèdent à n’importe quelle table du schéma db.sch peuvent être exécutés avec les privilèges SELECT et INSERT de l’appelant.

GRANT INHERITED CALLER SELECT, INSERT ON ALL TABLES IN SCHEMA db.sch TO ROLE owner_role;

Copy

Les exécutables appartenant à owner_role qui accèdent aux schémas du compte courant peuvent être exécutés avec tous les privilèges de l’appelant sur les schémas.

GRANT ALL INHERITED CALLER PRIVILEGES ON ALL SCHEMAS IN ACCOUNT TO ROLE owner_role;

Copy

Les exécutables appartenant au rôle de base de données db.r qui accèdent à la table db.sch1.t1 peuvent être exécutés avec le privilège SELECT sur la table.

GRANT CALLER SELECT ON TABLE db.sch1.t1 TO DATABASE ROLE db.r;

Copy

Les exécutables appartenant à owner_role qui accèdent à la base de données my_db peuvent s’exécuter avec tous les privilèges de l’appelant sur la base de données.

GRANT ALL CALLER PRIVILEGES ON DATABASE my_db TO ROLE owner_role;

Copy

Révoquer une autorisation de l’appelant¶

Les administrateurs utilisent l’instruction REVOKE pour révoquer les privilèges précédemment accordés au propriétaire d’un exécutable par l’intermédiaire d’une autorisation de l’appelant. Cette instruction comporte différentes variantes, en fonction de la manière dont vous souhaitez révoquer les autorisations accordées aux appelants.

REVOKE CALLER — Révoquer des privilèges spécifiques sur un objet spécifique.
REVOKE ALL CALLER PRIVILEGES — Révoquer tous les privilèges d’un objet spécifique. L’exécutable ne pourra pas s’exécuter avec les privilèges de l’appelant lorsqu’il tentera d’accéder à l’objet.
REVOKE INHERITED CALLER — Révoquer les autorisations de l’appelant sur tous les objets actuels et futurs du même type lorsqu’ils partagent un schéma, une base de données ou un compte commun. Seuls les privilèges figurant dans une liste spécifiée sont révoqués.
REVOKE ALL INHERITED CALLER PRIVILEGES — Révoquer les autorisations de l’appelant sur tous les objets actuels et futurs du même type lorsqu’ils partagent un schéma, une base de données ou un compte commun. Tous les privilèges sont révoqués ; l’exécutable ne pourra pas être exécuté avec les privilèges de l’appelant.

L’exécution d’une commande REVOKE INHERITED CALLER ou REVOKE ALL INHERITED CALLER PRIVILEGES ne révoque pas une autorisation de l’appelant accordée sur un objet spécifique du compte, de la base de données ou du schéma à l’aide d’une instruction GRANT CALLER. Par exemple, si vous avez accordé une autorisation à l’appelant sur la table my_db.sch1.t1 directement, l’exécution de REVOKE INHERITED CALLER SELECT ON ALL TABLES IN DATABASE my_db ... ne révoque pas le droit de l’appelant sur t1.

Pour la syntaxe complète, y compris les paramètres, de la révocation d’une autorisation de l’appelant, voir REVOKE CALLER.

Exemples¶

Les exécutables appartenant à owner_role ne peuvent plus s’exécuter avec les privilèges de l’appelant lorsqu’ils accèdent aux vues du compte courant.

REVOKE ALL INHERITED CALLER PRIVILEGES ON ALL VIEWS IN ACCOUNT FROM ROLE owner_role;

Copy

Les exécutables appartenant à owner_role ne peuvent plus s’exécuter avec le privilège USAGE lorsqu’ils accèdent au schéma db.sch1.

REVOKE CALLER USAGE ON SCHEMA db.sch1 FROM ROLE owner_role;

Copy

Répertorier les autorisations de l’appelant¶

Les utilisateurs peuvent utiliser la commande SHOW CALLER GRANTS pour dresser la liste des autorisations accordées aux appelants. Vous pouvez utiliser cette commande pour dresser la liste de toutes les autorisations des appelants accordées à un propriétaire spécifique (SHOW CALLER GRANTS TO. ..) ou pour dresser la liste de toutes les autorisations des appelants sur un objet spécifique (SHOW CALLER GRANTS ON. ..).

Si vous exécutez la commande SHOW CALLER GRANTS ON … pour un objet spécifique, chaque ligne peut indiquer l’un des éléments suivants :

Une autorisation de l’appelant a été accordée directement sur l’objet.

Par exemple, la sortie de SHOW CALLER GRANTS ON TABLE db.sch.t1 contient une ligne si l’administrateur a exécuté GRANT CALLER SELECT ON TABLE db.sch.t1.
L’objet a hérité d’une autorisation de l’appelant.

Par exemple, la sortie de SHOW CALLER GRANTS ON TABLE db1.sch.t1 contient une ligne si l’administrateur a exécuté GRANT INHERITED CALLER SELECT ON ALL TABLES IN SCHEMA db1.sch.
L’objet a été spécifié avec une clause IN, de sorte que les autres objets qu’il contient ont hérité des autorisations de l’appelant.

Par exemple, la sortie de SHOW CALLER GRANTS ON ACCOUNT contient une ligne si l’administrateur a exécuté GRANT INHERITED CALLER SELECT ON ALL TABLES IN ACCOUNT.
L’objet est un ancêtre d’un objet avec une autorisation de l’appelant hérité ainsi que le descendant de l’objet qui a été spécifié avec une clause IN qui a donné lieu à l’héritage.

Par exemple, SHOW CALLER GRANTS ON SCHEMA my_db.sch1 contient une ligne si l’administrateur a exécuté GRANT INHERITED CALLER SELECT ON ALL TABLES IN DATABASE my_db.

Sortie conditionnelle¶

La sortie de la commande SHOW CALLER GRANTS varie en fonction des privilèges du rôle d’exécution. Lorsqu’un utilisateur exécute SHOW CALLER GRANTS, les résultats ne contiennent que les objets sur lesquels il dispose d’au moins un privilège ; il ne peut découvrir l’existence d’un objet que s’il peut y accéder, même s’il existe un privilège d’appelant sur cet objet.

Par exemple, supposons qu’il existe une autorisation de l’appelant sur les bases de données DB1 et DB2. Supposons maintenant que le rôle R2 dispose du privilège USAGE sur DB1, mais d’aucun privilège sur DB2. Lorsque R2 exécute SHOW CALLER GRANTS, la sortie montre qu’il y a une autorisation de l’appelant sur DB1, mais ne liste pas DB2. Si R2 dispose de privilèges sur les deux bases de données, la sortie indiquera que l’autorisation de l’appelant se trouve sur les deux bases de données.

Exemples¶

Listez les autorisations accordées à l’appelant sur la table t1.

SHOW CALLER GRANTS ON TABLE t1;

Copy

Listez toutes les autorisations accordées à l’appelant pour le compte courant. Il s’agit notamment des autorisations accordées directement au compte (GRANT CALLER … ON ACCOUNT) et des autorisations accordées à tous les objets d’un compte (GRANT INHERITED CALLER … IN ACCOUNT).

SHOW CALLER GRANTS ON ACCOUNT;

Copy

Dressez la liste de toutes les autorisations accordées à l’appelant pour le rôle de base de données db.owner_role.

SHOW CALLER GRANTS TO DATABASE ROLE db.owner_role;

Copy

Limites des autorisations accordées aux appelants¶

Les autorisations de l’appelant ne sont ni répliquées ni clonées.

Limites d’un exécutable dont les droits de l’appelant sont restreints¶

Si un exécutable s’exécute avec des droits d’appelant restreints, il est soumis aux restrictions suivantes.

Zones de préparation externes

L’exécutable ne peut pas créer de zone de préparation externe sans spécifier d’intégration de stockage.
L’exécutable ne peut pas être copié dans une zone de préparation externe.
L’exécutable ne peut pas être copié dans une URL externe sans spécifier une intégration de stockage.

Procédures stockées

L’exécutable ne peut pas créer d’objets Snowflake qui s’exécutent avec les droits du propriétaire, les droits de l’appelant ou les droits restreints de l’appelant. Par exemple, il ne peut pas créer de procédure stockée.
L’exécutable ne peut pas modifier les droits avec lesquels une procédure stockée s’exécute. Par exemple, l’exécutable ne peut pas faire passer une procédure stockée des droits du propriétaire aux droits de l’appelant.

Rôles et privilèges

L’exécutable ne peut pas exécuter les commandes USE ROLE et USE SECONDARY ROLES.
L’exécutable ne peut pas utiliser les instructions GRANT pour accorder des privilèges et des autorisations à l’appelant.
L’exécutable ne peut pas utiliser les instructions REVOKE pour révoquer les privilèges et les autorisations de l’appelant.

Références

L’exécutable ne peut pas créer de références transitoires et persistantes.

Opérations liées à la session

L’exécutable ne peut pas exécuter les commandes SET ou UNSET.
L’exécutable ne peut pas exécuter SHOW VARIABLES ou SHOW PARAMETERS.
L’exécutable ne peut pas utiliser ou lire les variables de session.
L’exécutable ne peut pas exécuter ALTER SESSION.
L’exécutable ne peut pas créer d’objets temporaires à l’échelle de la session.
L’exécutable ne peut pas exécuter USE DATABASE, USE SCHEMA ou USE WAREHOUSE.