Définir le Process Group Identifier (GID)

qu’elles ne s’appliquent pas au monde QSYS.LIB. En effet, la documentation est trompeuse : elle donne l’impression qu’elles ne peuvent être utilisées que par des applications portées à partir d’Unix. Ce n’est pas le cas.

Un UID est la représentation numérique d’un profil utilisateur que i5/OS attribue chaque fois qu’un profil est créé. De la même manière, i5/OS attribue un GID quand un profil de groupe est créé. Diverses interfaces et fonctions dans l’IFS utilisent les UID et les GID plutôt que les noms de profils, pour identifier les utilisateurs et leurs groupes.

Les API qsyseteuid() et qsysetegid() vous permettent de changer indépendamment le groupe utilisateur d’un thread. L’API qsyseteuid() change l’utilisateur mais pas le groupe associé au thread ; l’API qsysetegid() change le premier profil de groupe mais pas le profil utilisateur du thread (figure 3).

L’API qsysetegid() permet de définir le premier profil de groupe de l’utilisateur d’une application comme le profil qui possède l’application. En général, il n’est pas bon que les utilisateurs de l’application soient membres du profil qui possède l’application, parce que cela donne à tous les utilisateurs de l’application des droits de propriété sur elle. Mais c’est différent quand on utilise qsysetegid(). Bien que l’API mette à jour la liste de groupes du thread en modifiant le profil « effectif » ou le premier profil de groupe courant de l’utilisateur, elle ne modifie pas le profil de l’utilisateur de l’application. Autrement dit, l’utilisateur a seulement le profil d’application comme son premier groupe pour le thread dans lequel l’API a été appelée. Si l’utilisateur tente d’accéder aux fichiers d’application dans un autre processus, il n’y parvient pas parce que le propriétaire de l’application n’est pas le premier groupe de l’utilisateur.

Vous pouvez exécuter l’API qsysetegid() dans le programme initial de l’utilisateur d’application avant d’invoquer le menu de l’application. Tant que l’utilisatrice Carol est dans l’application, elle a suffisamment d’autorité sur les objets application parce qu’ils sont dotés de l’autorité du propriétaire de l’application. En revanche, dès qu’elle sort de l’application, l’accès lui est refusé. Contrairement à l’autorité adoptée, cette méthode d’autorisation est reconnue lorsqu’on accède à des objets dans l’IFS. De la même manière que l’autorité adoptée, si on choisit une option du menu pour soumettre un job au batch, le GID doit être à nouveau défini dans le job soumis. Comme dans le cas de la permutation de profils, il faut ajouter du code pour que le profil de l’application soit rétabli au groupe original, si le programme se termine de façon anormale.

IBM fournit un ensemble complet d’API pour travailler avec l’UID et le GID d’un thread. Le code de la figure 4 montre comment appeler ces API dans un programme RPG. Cet exemple de code peut être téléchargé sur www.itpro.fr Club abonnés