Améliorer l’intégrité

ALWSYSRQS
(figure 3) pour leur permettre
de l’utiliser. BLKSYSRQS et ALWSYSRQS
communiquent entre eux en
mettant à  jour une zone de données
dans la bibliothèque QTEMP. La zone
de données est placée dans QTEMP
pour deux raisons : (1) pour ne pas
avoir à  supprimer la zone de données à 
la fin du job et (2) pour éviter d’avoir à 
lui donner un nom unique qui est facile
à  générer dans les trois programmes.
(Dériver un tel nom du nom de
job courant est risqué parce que deux
jobs actifs peuvent avoir le même numéro.)
L’utilisation des trois programmes
améliore la sécurité et l’intégrité des
applications (nous reviendrons sur
l’amélioration de la sécurité plus loin).
Pour améliorer l’intégrité, vous pouvez
appeler BLKSYSRQS et ALWSYSRQS
autour des points critiques dans votre
application qui ne doivent pas être interrompus
par les fonctions System
Request. J’ai conçu ces programmes
pour mettre à  jour un compteur dans
une zone de données afin de pouvoir
les utiliser à  des niveaux d’appel multiples
dans l’application sans qu’il y ait
interférence entre eux. Par exemple,
un programme qui utilise BLKSYSRQS
et ALWSYSRQS peut en toute sécurité
appeler un module qui emploie aussi
ces programmes et System Request ne
sera pas autorisé par ce module quand
il se terminera. Pour utiliser BLKSYSRQS
et ALWSYSRQS, suivez simplement
cette règle : il faut appeler les
deux programmes le même nombre de fois. Il est particulièrement important
de ne jamais appeler ALWSYSRQS plus
de fois que vous avez déjà  appelé BLKSYSRQS
parce que ALWSYSRQS ne décrémente
jamais le compteur au-dessous
de zéro.
Outre la mise à  jour de la zone de
données, BLKSYSRQS appelle l’API
QWTSETPX pour s’assurer que le programme
de sortie de presystem request
sera appelé pour l’utilisateur
courant. Comme cette API est livrée
avec l’autorité *EXCLUDE publique, le
programme BLKSYSRQS doit adopter
l’autorité de son propriétaire et appartenir
à  un profil utilisateur ayant l’autorité
*USE sur l’API. Le programme n’a
pas besoin d’appartenir à  QSYS ou à 
tout autre profil utilisateur ayant l’autorité
spéciale *ALLOBJ.
CHKSYSRQS ne vérifie pas l’autorité
d’un utilisateur, donc il peut empêcher
tous les utilisateurs, y compris
ceux avec l’autorité spéciale *ALLOBJ,
d’utiliser System Request. Bien entendu,
un utilisateur avec l’autorité
spéciale *ALLOBJ peut supprimer le
programme CHKSYSRQS pour le préserver
des appels.
Pour protéger la zone de données
dans QTEMP d’une suppression accidentelle
ou involontaire, je l’ai modifiée
afin qu’elle appartienne au même
profil utilisateur que celui qui possède
le programme BLKSYSRQS. Cela a été
possible parce que le programme
adopte l’autorité de son propriétaire.
Pour déterminer le propriétaire du
programme, nous devons connaître le
nom de la bibliothèque du programme.
Pour les exemples décrits
dans cet article, tous les programmes
se trouvent dans une bibliothèque
nommée SYSRQS. Si cette bibliothèque
n’est pas présente sur votre
système, vous pouvez ajouter les instructions
de la figure 4 aux exemples
pour déterminer les noms et les bibliothèques
des programmes. Une autre
solution consiste à  utiliser l’API QWVRCSTK
(Retrieve Call Stack) V5R1.
Voyons maintenant comment le
programme PMTPWD utilise les programmes
BLKSYSRQS et ALWSYSRQS
pour empêcher les utilisateurs de se
servir temporairement de System
Request.