> Tech > Les détails techniques de l’adoption

Les détails techniques de l’adoption

Tech - Par iTPro - Publié le 22 février 2012
email


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. 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 gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 22 février 2012