Cette semaine, une boîte à outils portant sur le développement d'applications et l'utilisation des propriétés dans dans l'environnement i notamment.
Un dossier spécial développeur avec cette boîte à outils. Au programme, la construction d'une commande CL SCAN, l'utilisation de Free Format, la date du job et de la date du système, les serveurs hôtes, la propriété d’un objet..
L’autorité adoptée est une méthode puissante pour augmenter temporairement l’autorité d’un job, afin qu’il puisse accéder à des objets ou à des données auxquels l’utilisateur n’a normalement pas accès. L’autorité adoptée est toujours basée sur un objet programme et sur la propriété du programme.
Et elle n’est reconnue que dans le système de fichiers QSYS.LIB. En général, un programme peut adopter l’autorité depuis une source autre que le profil utilisateur actuellement actif, de l’une des deux manières suivantes :
Le seul moyen de faire cela passe par l’utilisation de la commande CHGPMG. USEADPAUT est réglé sur *NO à la première création du programme. Vous pouvez utiliser la valeur système QUSEADPAUT pour spécifier une liste d’autorisations à contrôler qui est autorisée à changer un programme en USEADPAUT(*YES).
Bien que l’autorité adoptée soit utile pour obtenir une autorité adéquate pour des activités spécifiques et pertinentes, il faut l’utiliser avec prudence. En effet, si une autorité adoptante de programme provenant d’un profil utilisateur puissant appelle un autre programme ou commande, lequel à son tour met une ligne de commande à la disposition de l’utilisateur, celui-ci pourra exécuter des commandes sous l’autorité adoptée du puissant utilisateur.
Malheureusement, il n’existe aucun attribut de programme pour contrôler si l’autorité adoptée au niveau d’invocation courant devrait être disponible pour que le prochain niveau d’invocation puisse l’utiliser – c’est ce qu’on appelle aussi la propagation d’autorité. L’attribut d’autorité d’invocation Modify intégrée à ILE MI (‘_MODINVAU’) est, cependant, disponible pour tous les compilateurs ILE, et cette fonction intégrée peut définir l’attribut de propagation d’autorité pour l’invocation courante d’un programme, sans affecter de manière permanente l’objet programme. J’ai écrit un petit programme de test pour démontrer comment la fonction MODINVAU affecte l’autorité adoptée propagée.
Veuillez compiler et changer le programme CBX605, en suivant soigneusement les instructions de l’en-tête source. Cette situation requiert l’accès au profil utilisateur QSECOFR. Voici la séquence d’événements qui se déroule quand vous appelez le programme de test :
Appuyez sur F3 pour mettre fin au programme de test. Pour que ce test fonctionne, le profil exécutant le programme de test doit avoir LMTCPB(*NO). L’autorité adoptée ne remplace pas cet attribut du profil utilisateur. Et si vous avez des programmes ILE qui adoptent l’autorité et restent dans la pile de programmes, propageant par conséquent et par mégarde l’autorité adoptée à d’autres programmes, vous pouvez copier la fonction MODINVAU utilisée dans le programme de test ci-dessus pour éliminer ce risque.
La fonction intégrée _MODINVAU est documentée à cette adresse.
– Carsten Flensburg
Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.
