Les droits sur les objets, qui peut faire quoi
Sur IBM i, chaque objet dit qui peut s'en servir et comment. Voici les droits *USE, *CHANGE, *ALL et *EXCLUDE, le rôle du propriétaire, du public et des groupes, l'ordre dans lequel le système vérifie, et neuf essais réels qui montrent les pièges.
En une phrase
Chaque objet porte ses droits : celui de son propriétaire, des droits privés donnés à des utilisateurs ou à des groupes, et un droit public pour tous les autres. Pour chaque opération, le système vérifie le droit sur la bibliothèque, puis sur l'objet, dans un ordre précis, et s'arrête au premier droit trouvé.
Qui a un droit sur un objet ?
- Le propriétaire : tout objet en a un, celui qui l'a créé (ou son groupe, si son
profil le demande). Il a
*ALLpar défaut. Il peut se retirer des droits, par prudence (par exemple le droit de supprimer un fichier critique), et se les redonner quand il veut. - Les droits privés : un droit donné nommément à un profil, utilisateur ou groupe. Un membre reçoit le droit de son groupe, sauf s'il a son propre droit sur l'objet.
- Le public (
*PUBLIC) : toute personne qui peut se connecter. Chaque objet a un droit public, éventuellement*EXCLUDE; il s'applique quand aucun autre droit n'est trouvé. - Le groupe principal : un groupe dont le droit est stocké dans l'objet même, ce qui accélère la vérification. Seul un profil qui a un numéro de groupe (gid) peut l'être.
*USE, *CHANGE, *ALL et *EXCLUDE
Un droit est fait de droits élémentaires, sur l'objet lui-même et sur ses données. En pratique, on utilise presque toujours l'un des quatre droits prédéfinis, dont voici la composition d'après IBM :
| Droit élémentaire | *ALL | *CHANGE | *USE | *EXCLUDE |
|---|---|---|---|---|
*OBJOPR |
✓ | ✓ | ✓ | |
*OBJMGT |
✓ | |||
*OBJEXIST |
✓ | |||
*OBJALTER |
✓ | |||
*OBJREF |
✓ | |||
*READ |
✓ | ✓ | ✓ | |
*ADD |
✓ | ✓ | ||
*UPD |
✓ | ✓ | ||
*DLT |
✓ | ✓ | ||
*EXECUTE |
✓ | ✓ | ✓ |
*USE: lire et exécuter. C'est le bon droit pour consulter.*CHANGE: en plus, ajouter, modifier et supprimer le contenu. Mais pas supprimer l'objet : il lui manque*OBJEXIST(essai 5b ci-dessous).*ALL: tout, y compris supprimer, déplacer, renommer l'objet et gérer ses droits.*EXCLUDE: aucun accès. Attention, ce n'est pas l'absence de droit : sans droit propre, on reçoit le droit public ; avec*EXCLUDE, la vérification s'arrête sur un refus. Seuls un droit spécial*ALLOBJ(vérifié avant) et des droits adoptés passent outre.
Le détail des onze droits élémentaires
Droits sur l'objet
*OBJOPROpérationnel | Voir la description de l'objet ; l'utiliser selon ses droits sur les données. |
|---|---|
*OBJMGTGestion | Régler la sécurité de l'objet, le déplacer, le renommer. |
*OBJEXISTExistence | Supprimer l'objet, libérer son espace, le sauvegarder et le restaurer, en changer le propriétaire. |
*OBJALTERModification | Ajouter, vider, réorganiser les membres d'un fichier, changer ses attributs, ajouter des triggers. |
*OBJREFRéférence | Désigner un fichier comme parent d'une contrainte d'intégrité référentielle. |
*AUTLMGTGestion de liste | Ajouter et retirer des utilisateurs d'une liste d'autorisation. |
Droits sur les données
*READLecture | Lire le contenu : les enregistrements d'un fichier, par exemple. |
|---|---|
*ADDAjout | Ajouter des entrées : enregistrements, messages. |
*UPDMise à jour | Modifier des entrées existantes. |
*DLTSuppression | Supprimer des entrées (pas l'objet). |
*EXECUTEExécution | Exécuter un programme ; trouver un objet dans une bibliothèque. |
Les fichiers de la base de données ont aussi des droits par zone, réglés en SQL par GRANT et REVOKE. L'IFS utilise de son côté *RWX, *RW, *RX, *R… (commandes WRKAUT et CHGAUT).
DSPOBJAUT affiche les droits d'un objet ; F11 bascule entre le droit global, le détail des droits sur l'objet et le détail des droits sur les données. Voici notre zone de données DTA3 :

DSPOBJAUT OBJ(JOBIPRF/DTA3) OBJTYPE(*DTAARA) : public *EXCLUDE, le groupe JOBIGRP en *CHANGE, l'utilisateur JOBIUSER en *USE.
*USE = lecture et exécution.D'abord la bibliothèque, puis l'objet
Pour accéder à un objet, il faut un droit sur l'objet et sur la bibliothèque qui le
contient. *USE sur la bibliothèque suffit pour la plupart des opérations, y compris
supprimer un objet (si l'on a le droit de le faire sur l'objet) ; créer un objet demande
*ADD sur la bibliothèque. Notre essai 7 le montre : une zone de données publique
*ALL, rangée dans une bibliothèque publique *EXCLUDE, reste
inaccessible.
CPF1022 Non autorisé à bibliothèque JOBISEC pour zone de données DTA7.
C'est la sécurité par bibliothèque qu'IBM propose pour rester simple : ranger les
fichiers confidentiels d'une application dans une bibliothèque, laisser à ses objets un droit public
suffisant pour l'application (*USE ou *CHANGE), mettre la bibliothèque
elle-même en *EXCLUDE, et ne donner le droit sur la bibliothèque qu'aux groupes
concernés. IBM précise que ce n'est pas assez pour des données très sensibles, qu'il vaut mieux
protéger objet par objet ou par une liste
d'autorisation.
Un détail qui compte : le droit sur une bibliothèque de la liste de bibliothèques est mémorisé quand elle y est ajoutée, et reste valable pour tout le travail, même si on le retire entre temps.
L'ordre de vérification, et le piège
Une fois la bibliothèque franchie, le système cherche un droit sur l'objet dans cet ordre :
*USE et son groupe
*CHANGE, il n'aura que *USE.
Notre essai 3 le prouve. Sur DTA3, le groupe JOBIGRP a *CHANGE et l'utilisateur
JOBIUSER, membre du groupe, a *USE (capture ci-dessus). JOBIUSER essaie de modifier la
zone de données :
CHGDTAARA DTAARA(JOBIPRF/DTA3 *ALL) VALUE('Modifiee')
CPF1018 Non autorisé à modifier la zone de données.
Refusé : son propre *USE a été trouvé avant le *CHANGE du groupe. C'est
aussi pourquoi IBM recommande d'éviter les droits privés inférieurs au droit public de l'objet. Les droits de plusieurs groupes, eux, se cumulent pour atteindre le droit demandé.
Neuf essais sur un IBM i 7.5
Nous avons préparé des objets avec des droits différents, puis lancé un programme CL sous le profil
JOBIUSER (classe *USER, sans droit spécial, membre du groupe JOBIGRP). Chaque essai est tenté, et
l'historique du travail 012150/JOBIUSER/TESTDROITS donne le résultat :
| Essai | Objet et droits | Action | Résultat |
|---|---|---|---|
| 1 | DTA1public *EXCLUDE |
lire (RTVDTAARA) | refusé : CPF1016 Non autorisé à utiliser la zone de données DTA1 de JOBIPRF. |
| 2a | DTA2public *EXCLUDE, groupe JOBIGRP *USE |
lire | permis |
| 2b | DTA2public *EXCLUDE, groupe JOBIGRP *USE |
modifier (CHGDTAARA) | refusé : CPF1018 Non autorisé à modifier la zone de données. |
| 3 | DTA3groupe JOBIGRP *CHANGE, utilisateur JOBIUSER *USE |
modifier | refusé : CPF1018 Non autorisé à modifier la zone de données. |
| 4a | DTA4public *USE |
lire | permis |
| 4b | DTA4public *USE |
modifier | refusé : CPF1018 Non autorisé à modifier la zone de données. |
| 5a | DTA5public *CHANGE |
modifier | permis |
| 5b | DTA5public *CHANGE |
supprimer (DLTDTAARA) | refusé : CPF2189 Utilisation de l'objet DTA5 de JOBIPRF, type *DTAARA non autorisée. |
| 6 | DTA6public *AUTL, liste JOBIAUTL : JOBIUSER *CHANGE |
modifier | permis |
| 7 | JOBISEC/DTA7objet public *ALL, bibliothèque public *EXCLUDE |
lire | refusé : CPF1022 Non autorisé à bibliothèque JOBISEC pour zone de données DTA7. |
| 8a | SECRETpublic *EXCLUDE, JOBIAPP *USE |
lire directement | refusé : CPF1016 Non autorisé à utiliser la zone de données SECRET de JOBIPRF. |
| 8b | SECRETpublic *EXCLUDE, JOBIAPP *USE |
lire par LIRESECR (USRPRF(*OWNER), propriétaire JOBIAPP) | permis LIRESECR a lu SECRET : Code 1234 |
| 9a | CLIENTSpublic *EXCLUDE, groupe JOBIGRP *USE |
lire (CPYF) | permis 2 enregistrement(s) du membre CLIENTS copié(s). |
| 9b | CLIENTSpublic *EXCLUDE, groupe JOBIGRP *USE |
ajouter une ligne (INSERT) | refusé : CPF4269 Non autorisé à l'objet CLIENTS de JOBIPRF type *FILE. (puis SQL0551) |
Ce que l'on en retient :
- Essai 2 : le droit du groupe s'applique à ses membres (lecture permise), mais
*USEne permet pas de modifier. - Essai 5 :
*CHANGEmodifie le contenu, mais ne supprime pas l'objet (CPF2189). - Essai 9 : une table SQL est un fichier comme les autres. Avec
*USEon la lit (2 lignes copiées), l'INSERT est refusé par CPF4269 puis SQL0551. - Les essais 6 et 8 utilisent une liste d'autorisation et un programme qui adopte les droits : ils sont expliqués sur la page suivante.
Le programme d'essai TESTDROITS
/* Neuf essais d'accès, lancés sous le profil JOBIUSER (groupe JOBIGRP). */
/* Chaque essai est annoncé par un message, puis tenté ; une erreur ne */
/* l'arrête pas (MONMSG) : l'historique du travail garde le résultat. */
PGM
DCL VAR(&V) TYPE(*CHAR) LEN(20)
SNDPGMMSG MSG('ESSAI 1 : lire DTA1 (public *EXCLUDE)') TOPGMQ(*EXT)
RTVDTAARA DTAARA(JOBIPRF/DTA1) RTNVAR(&V)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 2a : lire DTA2 (groupe *USE)') TOPGMQ(*EXT)
RTVDTAARA DTAARA(JOBIPRF/DTA2) RTNVAR(&V)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 2b : modifier DTA2 (groupe *USE)') TOPGMQ(*EXT)
CHGDTAARA DTAARA(JOBIPRF/DTA2) VALUE('Modifiee')
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 3 : modifier DTA3 (groupe *CHANGE, +
utilisateur *USE)') TOPGMQ(*EXT)
CHGDTAARA DTAARA(JOBIPRF/DTA3) VALUE('Modifiee')
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 4a : lire DTA4 (public *USE)') TOPGMQ(*EXT)
RTVDTAARA DTAARA(JOBIPRF/DTA4) RTNVAR(&V)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 4b : modifier DTA4 (public *USE)') TOPGMQ(*EXT)
CHGDTAARA DTAARA(JOBIPRF/DTA4) VALUE('Modifiee')
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 5a : modifier DTA5 (public *CHANGE)') TOPGMQ(*EXT)
CHGDTAARA DTAARA(JOBIPRF/DTA5) VALUE('Modifiee')
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 5b : supprimer DTA5 (public *CHANGE)') TOPGMQ(*EXT)
DLTDTAARA DTAARA(JOBIPRF/DTA5)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 6 : modifier DTA6 (liste JOBIAUTL, +
utilisateur *CHANGE)') TOPGMQ(*EXT)
CHGDTAARA DTAARA(JOBIPRF/DTA6) VALUE('Modifiee')
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 7 : lire JOBISEC/DTA7 (objet public +
*ALL, bibliothèque *EXCLUDE)') TOPGMQ(*EXT)
RTVDTAARA DTAARA(JOBISEC/DTA7) RTNVAR(&V)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 8a : lire SECRET directement') TOPGMQ(*EXT)
RTVDTAARA DTAARA(JOBIPRF/SECRET) RTNVAR(&V)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 8b : lire SECRET par le programme +
LIRESECR qui adopte') TOPGMQ(*EXT)
CALL PGM(JOBIPRF/LIRESECR)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 9a : lire la table CLIENTS (groupe +
*USE)') TOPGMQ(*EXT)
CPYF FROMFILE(JOBIPRF/CLIENTS) TOFILE(QTEMP/CLIENTS) +
CRTFILE(*YES)
MONMSG MSGID(CPF0000)
SNDPGMMSG MSG('ESSAI 9b : ajouter une ligne à CLIENTS +
(groupe *USE)') TOPGMQ(*EXT)
RUNSQL SQL('INSERT INTO JOBIPRF.CLIENTS VALUES(3, +
''Durand'')') COMMIT(*NONE)
MONMSG MSGID(CPF0000 SQL0000)
SNDPGMMSG MSG('FIN DES ESSAIS') TOPGMQ(*EXT)
ENDPGM
Donner et retirer des droits
Les commandes que nous avons utilisées pour préparer les essais :
/* Créer l'objet avec son droit public */
CRTDTAARA DTAARA(JOBIPRF/DTA3) TYPE(*CHAR) LEN(20) AUT(*EXCLUDE)
/* Droits privés : au groupe, puis à un utilisateur */
GRTOBJAUT OBJ(JOBIPRF/DTA3) OBJTYPE(*DTAARA) USER(JOBIGRP) AUT(*CHANGE)
GRTOBJAUT OBJ(JOBIPRF/DTA3) OBJTYPE(*DTAARA) USER(JOBIUSER) AUT(*USE)
/* Changer le droit public d'un objet existant */
RVKOBJAUT OBJ(JOBIPRF/CLIENTS) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*ALL)
GRTOBJAUT OBJ(JOBIPRF/CLIENTS) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*EXCLUDE)
Pour corriger le piège de l'essai 3, il suffit de retirer le droit privé de l'utilisateur, qui
retombe alors sur celui de son groupe :
RVKOBJAUT OBJ(JOBIPRF/DTA3) OBJTYPE(*DTAARA) USER(JOBIUSER) AUT(*ALL).
Nous l'avons vérifié : après ce retrait, la même modification soumise sous JOBIUSER a abouti
(code de fin 0). En SQL, les droits d'une table se donnent aussi par GRANT et REVOKE, et
QSYS2.OBJECT_PRIVILEGES les liste tous :
SELECT SYSTEM_OBJECT_NAME, OBJECT_TYPE, AUTHORIZATION_NAME,
OBJECT_AUTHORITY, OWNER
FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = 'JOBIPRF'
Le droit public des nouveaux objets : CRTAUT et QCRTAUT
Quand on crée un objet sans préciser AUT, la plupart des commandes de création
prennent la valeur *LIBCRTAUT : le droit public vient du paramètre CRTAUT de sa
bibliothèque. Celui-ci vaut *SYSVAL par défaut, c'est-à-dire la valeur système
QCRTAUT, livrée à *CHANGE.

DSPLIBD JOBIPRF : « Droits pour objets créés » vaut *SYSVAL.Sur notre IBM i 7.5, QCRTAUT a été mis à *EXCLUDE. Une zone de données créée dans
JOBIPRF sans paramètre AUT a donc reçu *PUBLIC *EXCLUDE. Et la même règle vaut pour
les bibliothèques, car QSYS a lui aussi CRTAUT(*SYSVAL) : une bibliothèque créée par
un simple CRTLIB sur ce système naît en *PUBLIC *EXCLUDE (nous l'avons
vérifié avec une bibliothèque de test). Nous nous y
sommes pris nous-mêmes en préparant la rubrique sur les travaux :
le profil de test a reçu « Non autorisé à la description de travail DEMOJOBD dans JOBITRV » :
la bibliothèque JOBITRV, créée par un simple CRTLIB, était en *PUBLIC *EXCLUDE.
- IBM conseille de régler le
CRTAUTd'une bibliothèque sur le droit public de la plupart de ses objets. - CRTAUT ne joue pas pour un objet déplacé (MOVOBJ), dupliqué (CRTDUPOBJ) ou restauré : il garde
son droit public. Avec
REPLACE(*YES), l'objet recréé reprend les droits de l'ancien. - Contrôlez qui peut changer la description d'une bibliothèque d'application : changer son CRTAUT change le droit de tous les objets créés ensuite.
Les commandes des droits
| GRTOBJAUT | Donner un droit sur un ou plusieurs objets. |
|---|---|
| RVKOBJAUT | Retirer un droit. |
| EDTOBJAUT | Modifier les droits d'un objet à l'écran. |
| DSPOBJAUT | Afficher les droits d'un objet. |
| CHGOBJOWN | Changer le propriétaire d'un objet. |
| CHGOBJPGP | Changer le groupe principal d'un objet. |
| GRTUSRAUT | Donner à un utilisateur les mêmes droits privés qu'un autre. |
| CHGLIB | Changer le droit par défaut des nouveaux objets d'une bibliothèque (CRTAUT). |
| WRKOBJPVT | Les objets sur lesquels un profil a des droits privés. |
| WRKAUT | Les droits d'un objet de l'IFS ; CHGAUT les modifie. |
À retenir
- Il faut un droit sur la bibliothèque et sur l'objet.
*USElit,*CHANGEmodifie le contenu,*ALLgère l'objet ;*EXCLUDEinterdit.- Le premier droit trouvé gagne : un droit privé faible masque le droit du groupe.
- Sans AUT, un nouvel objet prend le CRTAUT de sa bibliothèque, souvent QCRTAUT.
Sources
Les exemples ont été créés et relevés sur un IBM i 7.5 (voir la méthode). Les définitions et les règles viennent de ces sources, consultées le 15 octobre 2026 :
- IBM i 7.5 Security : Security reference, IBM (PDF, 1 060 pages). Rôles du profil ; nom (10 caractères) et mot de passe (128 caractères en QPWDLVL 2 à 4) ; statut ; bibliothèque en cours, programme et menu initiaux, LMTCPB ; JOBD ; groupes (16 au plus, droits spéciaux cumulés) ; valeurs par défaut de CRTUSRPRF (table 151 : PASSWORD *NONE, AUT *EXCLUDE, PTYLMT 3) ; classes et droits spéciaux par niveau de sécurité (table 54) ; rôle et risques de chaque droit spécial ; ouverture d'une session et démarrage d'un batch ; QSECURITY 20 abandonné en 7.5 ; droits sur les objets (tables 116 et 117), sécurité par bibliothèque, listes d'autorisation, CRTAUT et QCRTAUT, propriété, droits adoptés et leurs risques, ordre de vérification des droits, recommandations générales.
- L'aide en ligne des commandes citées, livrée avec IBM i 7.5 et reprise en français dans les fiches des commandes CL de ce site. Paramètres de CRTUSRPRF, DLTUSRPRF, SBMJOB, PRTPUBAUT, PRTADPOBJ et PRTPVTAUT.
Questions fréquentes
Quelle différence entre *USE, *CHANGE et *ALL ?
*USE permet de lire et d'exécuter. *CHANGE y ajoute l'ajout, la mise à jour et la suppression du contenu. *ALL donne en plus la gestion de l'objet lui-même : le supprimer, le déplacer, changer ses droits. Avec *CHANGE, on modifie une zone de données mais on ne peut pas la supprimer : il manque le droit *OBJEXIST.
*EXCLUDE, est-ce la même chose que n'avoir aucun droit ?
Non. Sans droit propre, l'utilisateur reçoit le droit public de l'objet. *EXCLUDE est un droit trouvé qui interdit l'accès, et la vérification s'arrête là ; seuls *ALLOBJ et les droits adoptés passent outre.
Pourquoi mon utilisateur ne profite-t-il pas des droits de son groupe ?
Parce qu'il a son propre droit privé sur l'objet : le système s'arrête au premier droit trouvé, même insuffisant. Sur notre IBM i 7.5, un utilisateur *USE dont le groupe a *CHANGE n'a pas pu modifier la zone de données (CPF1018). Retirez son droit privé : il prendra celui du groupe.
Faut-il des droits sur la bibliothèque ?
Oui. Il faut un droit sur la bibliothèque et sur l'objet ; *USE sur la bibliothèque suffit pour la plupart des opérations, *ADD pour y créer un objet. Un objet public *ALL dans une bibliothèque *EXCLUDE reste inaccessible (CPF1022).
Comment donner un droit sur un objet ?
Avec GRTOBJAUT, par exemple GRTOBJAUT OBJ(MABIB/CLIENTS) OBJTYPE(*FILE) USER(GRPCOMPTA) AUT(*USE). RVKOBJAUT le retire, EDTOBJAUT modifie les droits à l'écran, DSPOBJAUT les affiche, et le service SQL QSYS2.OBJECT_PRIVILEGES les liste.