Autorisations IBM System i sur les vues de base de données

Nous avons un IBM System i exécutant IBM i OS v6r1. Sur ce système, j'ai créé des vues de base de données. Ce que je veux faire, c'est donner à un groupe d'utilisateurs particulier accès UNIQUEMENT à ces vues et à rien d'autre dans la bibliothèque dans laquelle résident les vues. Est-ce possible? J'ai eu un groupe d'utilisateurs qui avait des autorisations en lecture seule sur toutes les tables et vues de la bibliothèque dans laquelle se trouvent mes vues, et accède aux travaux lorsque l'utilisateur est sous ce groupe d'utilisateurs. J'ai essayé de copier le groupe d'utilisateurs, puis d'attribuer des autorisations pour n'inclure que les vues que j'ai créées, et l'accès est refusé. Un utilisateur ou un groupe d'utilisateurs doit-il également disposer d'autorisations sur la table d'où provient la vue pour accéder à la vue?

permissions ibm ibm-midrange

— Big EMPin
source

Pensez à publier ceci sur dba.stackexchange.com

— WarrenT

@WarrenT croyez-le ou non, il s'agit en fait autant d'une question d'administration système que d'une question de base de données pour iSeries / milieu de gamme - la base de données DB2 est étroitement intégrée à OS / 400 et, à la question, il semble que ce soient des autorisations OS / 400 sur le bibliothèque qui fait trébucher les choses. (Malheureusement, cela fait si longtemps que je ne me suis pas connecté à une boîte de milieu de gamme, je ne suis pas sûr à 100% comment résoudre le problème!)

— voretaq7

@ voretaq7 Oui. La base de données n'est pas seulement tissée dans l'essence du système d'exploitation, elle est conçue dans la machine elle-même (l'interface de la machine, MI). Cela fait plus d'une décennie que j'étais QSECOFR, donc je devrais chercher la réponse. Mais comme personne ici n'a encore répondu, et c'est un jeu équitable pour les deux sites, je pensais qu'il pourrait y avoir quelqu'un chez dba qui pourrait le savoir du haut de leur tête.

— WarrenT

Oui. Il ne suffit pas d'accorder l'autorisation d'utiliser une vue. L'utilisateur doit également disposer des droits d'accès à la table sous-jacente.

Une façon d'autoriser l'accès à un utilisateur restreint est d'adopter l'autorité. Par exemple, supposons ce qui suit:

L'utilisateur RESTRICTED n'a accès à aucune table. Toutes les bibliothèques sont AUT (* EXCLUDE) - ou - l'utilisateur RESTRICTED a le droit * EXCLUDE sur toutes les bibliothèques. L'UTILISATEUR PERMIS peut accéder (ou est propriétaire) des tables et des bibliothèques. La bibliothèque DATA a les tables. La bibliothèque PROGRAMMES contient les programmes et les procédures stockées.

Demandez à PERMIS de créer une procédure stockée RPG dans la bibliothèque PROGRAMMES. Assurez-vous que le programme a spécifié USRPRF (* OWNER). Cela signifie que lorsque le programme s'exécute, il utilise l'autorité du propriétaire (PERMIS) plutôt que l'autorité du profil qui l'exécute (RESTREINT).

Accordez à l'utilisateur PERMITTED * USE l'autorisation de l'objet programme RPG -ou- GRANT via SQL. En outre, accordez à l'utilisateur RESTRICTED * USE l'accès aux PROGRAMMES de la bibliothèque. Cela permettra à RESTRICTED d'exécuter la procédure / le programme stocké.

Notez que l'utilisateur RESTRICTED n'a pas le droit d'accéder aux tables dans DATA et vous souhaitez le laisser de cette façon.

Demandez maintenant à l'utilisateur RESTRICTED d'utiliser SQL pour APPELER la procédure stockée. Elle a le droit d'exécuter le programme car elle dispose des droits * USE sur la bibliothèque PROGRAMS ainsi que sur l'objet programme compilé. La procédure stockée s'exécute sous l'autorité du propriétaire, PERMITTED et puisque PERMITTED a un accès complet aux données de la bibliothèque et aux tables qui s'y trouvent, la procédure stockée peut accéder / mettre à jour ces tables. Tout SQL brut que RESTRICTED tente d'utiliser échouera en raison d'une autorité insuffisante - la seule chose qu'elle peut faire est d'appeler les procédures stockées créées pour elle.

Si vos programmes sont stockés dans la même bibliothèque que vos données, vous devrez donner le pouvoir RESTRICTED * USE à la bibliothèque et la restreindre spécifiquement (via * EXCLUDE) sur toutes les tables de cette bibliothèque. Il peut être plus facile de créer une bibliothèque RESTREINTE qui ne contient que les procédures stockées et de l'autoriser à cette bibliothèque. Cela rend la maintenance continue plus facile car vous n'aurez pas à vous souvenir de la restreindre aux nouvelles tables créées dans DATA.

— Buck Calabro
source