Le Propriétaire De L'objet De La Base De Données

Le propriétaire de l’objet de la base de données

L’utilisateur qui a créé un objet de base de données en devient le propriétaire. Seuls le propriétaire de l’objet et les utilisateurs ayant les privilèges administrateurs dans la base de données peuvent modifier ou supprimer l’objet de la base de données. Le propriétaire de la base de données, c’est-à-dire l’utilisateur qui l’a créé, dispose de tous les droits sur les objets qui ont été créés par d’autres utilisateurs.

Les administrateurs ou le propriétaire de l’objet peuvent accorder des privilèges à d’autres utilisateurs, y compris des privilèges pour accorder des privilèges à d’autres utilisateurs. Le processus réel d’octroi et de révocation des privilèges au niveau SQL est mis en œuvre par deux opérateurs :GRANT, REVOKE.

Privilèges d’exécution du code SQL

Tous les objets de métadonnées contenant du code DML ou PSQL peuvent être exécutés dans l’un des modes suivants :

Avec des privilèges d’utilisateur appelant (privilèges CURRENT_USER) ;
En définissant les privilèges de l’utilisateur (propriétaire de l’objet de métadonnées).

Historiquement, tous les modules PSQL sont exécutés avec les privilèges de l’utilisateur appelant par défaut.À partir de Firebird 4.0, il est maintenant possible de spécifier des objets de métadonnées à exécuter par l’utilisateur appelant ou définissant.Ceci est fait avec l’option SQL SECURITY, qui peut être spécifiée pour une table, un trigger, une procédure, une fonction ou un package.Si l’option INVOKER est sélectionnée, l’objet de métadonnées sera exécuté avec les privilèges de l’utilisateur appelant.Si l’option DEFINER est sélectionnée, l’objet de métadonnées sera exécuté avec les privilèges de l’utilisateur qui le définit (propriétaire). Ces privilèges s’ajouteront aux privilèges accordés au module PSQL lui-même à l’aide de l’opérateur GRANT.

Les privilèges d’exécution avec lesquels tout module PSQL est exécuté par défaut (non spécifiés par le module lui-même) peuvent être modifiés à l’aide de la commande

ALTER DATABASE SET DEFAULT SQL SECURITY {DEFINER | INVOKER}

L’option INVOKER est utilisée par défaut pour maintenir une compatibilité ascendante.

Note

Remarques

Les vues (VIEWs) sont toujours exécutées avec les privilèges de l’utilisateur qui les définit (propriétaire) ;
Par défaut, les déclencheurs héritent des privilèges d’exécution qui ont été spécifiés pour la table. Les privilèges d’exécution peuvent être remplacés dans le déclencheur lui-même ;
Les procédures et les fonctions du paquet héritent toujours des privilèges d’exécution spécifiés lors de la définition du paquet. Les privilèges d’exécution ne peuvent pas être remplacés dans les procédures et fonctions du paquet elles-mêmes ;
Les blocs PSQL anonymes (EXECUTE BLOCK) sont toujours exécutés avec les privilèges de l’appelant.

Dans les procédures stockées, les fonctions et les triggers, vous pouvez vérifier l’utilisateur effectif actuel, c’est-à-dire l’utilisateur dont les privilèges sont en cours d’exécution, en utilisant la variable de contexte système EFFECTIVE_USER de l’espace de noms SYSTEM.

select RDB$GET_CONTEXT('SYSTEM', 'EFFECTIVE_USER') from RDB$DATABASE;

Note

Le même objet peut être appelé dans différents contextes de sécurité et nécessiter des privilèges différents.Par exemple, nous avons :

une procédure stockée INV avec SECURITY INVOKER qui insère des enregistrements dans la table T ;
une procédure stockée DEF avec SQL SECURITY DEFINER qui est définie par l’utilisateur SYSDBA.

Si l’utilisateur U appelle la procédure INV, alors le privilège INSERT accordé à l’utilisateur U sera nécessaire pour accéder à la table T (et bien sûr le privilège EXECUTE pour INV). Dans ce cas, U est l’utilisateur effectif (EFFECTIVE_USER) lors de l’exécution de INV.

Si l’utilisateur U appelle la procédure DEF, le privilège INSERT accordé à l’utilisateur SYSDBA (et EXECUTE sur DEF pour l’utilisateur U) sera nécessaire pour accéder à la table T. Dans ce cas, SYSDBA est l’utilisateur effectif (EFFECTIVE_USER) lors de l’exécution de DEF.Si la procédure INV est appelée à l’intérieur de DEF, alors l’utilisateur effectif au moment de l’exécution de INV est aussi SYSDBA.