Le programme PAYMAINT est créé de telle manière que, quand il s’exécute, il adopte l’autorité du propriétaire du programme : ici PAYOWNER. Dès lors que BOB a adopté l’autorité de PAYOWNER, il a l’accès *ALL à la bibliothèque PAYDATA et au fichier PAYMST.
Les détails techniques de l’adoption
Comme le montre la figure 2, PAYOWNER a des droits *ALL sur la bibliothèque et le fichier.
Le truc qui fait que le programme PAYMAINT peut adopter l’autorité est que le programme a été créé en utilisant l’option du compilateur USRPRF(*OWNER), comme dans :
CRTBNDRPG PGM(PAYOBJ/
PAYMAINT)
USRPRF(*OWNER)
SRCFILE(MYLIB/
QRPGLESRC)
SRCMBR(PAYMAINT)
Si un programme existe déjà, il peut être changé pour adopter l’autorité en utilisant la commande CHGPGM :
CHGPGM PGM(PAYOBJ/PAYMAINT USRPRF(*OWNER)
Quand vous utilisez USRPRF(*OWNER), vous précisez que quand ce programme s’exécute, il utilisera les autorités combinées de l’utilisateur du programme et du propriétaire du programme pour déterminer les droits d’autorité sur l’objet. Si l’utilisateur n’est pas autorisé pour un fichier ou un programme demandé dans le job, le système vérifie si le propriétaire du programme est autorisé. Si l’un ou l’autre est autorisé, l’accès est accordé, mais si aucun n’est autorisé, l’accès est refusé.
L’autre option pour l’attribut de programme USRPRF est USRPRF(*USER), qui est la valeur par défaut. Cela signifie que quand ce programme s’exécute, il le fait sous l’autorité de l’utilisateur exécutant le programme. C’est le paramétrage normal pour cet attribut de programme dans un programme non adoptant.
Quand vous adoptez l’autorité, vous adoptez l’autorité du propriétaire du programme. Il est important de donner la propriété du programme au bon utilisateur. Ici nous donnons la propriété du programme PAYMAINT à l’utilisateur PAYOWNER.
CHGOBJOWN OBJ(PAYOBJ/PAYMAINT)
OBJTYPE(*PGM) NEWOWN(PAYOWNER)
En matière d’adoption d’autorité, n’adoptez que ce dont vous avez besoin, pas plus. Dans cet exemple, nous aurions pu adopter l’autorité QSECOFR en changeant le propriétaire du programme en QSECOFR, mais c’est beaucoup trop de pouvoir pour la tâche en question. Nous voulons simplement que BOB puisse manipuler les fichiers de paie, donc nous adoptons l’autorité du propriétaire des données de paie, PAYOWNER.
Dans la figure 2, observez que le programme adoptant PAYMAINT a son propre ensemble de jeux d’autorités sur l’objet visant à restreindre l’usage du programme. Les seuls utilisateurs autorisés à exécuter ce programme sont PAYOWNER et les membres du groupe PAYUSER. *PUBLIC est *EXCLUDE et ne peut pas exécuter ce programme.
Comme le programme PAYMAINT adopte l’autorité de PAYOWNER et donne accès pour maintenir le fichier de paie, vous voulez que les gens puissent utiliser ce programme uniquement s’ils sont membres du groupe PAYUSER du service de paie, comme l’est BOB. Si le *PUBLIC avait l’autorité *USE sur le programme, quiconque pourrait exécuter le programme et mettre à jour la paie. Protégez vos programmes adoptants de telle sorte que seuls les utilisateurs finaux d’applications licites aient le droit d’exécuter le programme.
Téléchargez cette ressource
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Redéfinir la confiance à l’ère de l’IA agentique : les entreprises sont-elles prêtes pour le SOC autonome ?
- IA Agentique : la vraie rupture c’est la gouvernance humaine
- Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
- Les nouvelles menaces liées à l’IA obligent les entreprises à dépasser la seule stratégie de sauvegarde
Articles les + lus
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
À la une de la chaîne Tech
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
