Aller au contenu
Profils et droits · 3 / 4

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.

4droits prédéfinis : *ALL, *CHANGE, *USE, *EXCLUDE
11droits élémentaires sur l'objet et ses données
9étapes de vérification, du chemin rapide aux droits adoptés
9essais réels sur notre IBM i 7.5

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 *ALL par 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érationnelVoir la description de l'objet ; l'utiliser selon ses droits sur les données.
*OBJMGTGestionRégler la sécurité de l'objet, le déplacer, le renommer.
*OBJEXISTExistenceSupprimer l'objet, libérer son espace, le sauvegarder et le restaurer, en changer le propriétaire.
*OBJALTERModificationAjouter, vider, réorganiser les membres d'un fichier, changer ses attributs, ajouter des triggers.
*OBJREFRéférenceDésigner un fichier comme parent d'une contrainte d'intégrité référentielle.
*AUTLMGTGestion de listeAjouter et retirer des utilisateurs d'une liste d'autorisation.

Droits sur les données

*READLectureLire le contenu : les enregistrements d'un fichier, par exemple.
*ADDAjoutAjouter des entrées : enregistrements, messages.
*UPDMise à jourModifier des entrées existantes.
*DLTSuppressionSupprimer des entrées (pas l'objet).
*EXECUTEExécutionExé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 :

Écran 5250 Droits sur un objet DTA3 de JOBIPRF : propriétaire SAKADM, *PUBLIC *EXCLUDE, SAKADM *ALL, JOBIGRP *CHANGE, JOBIUSER *USE
DSPOBJAUT OBJ(JOBIPRF/DTA3) OBJTYPE(*DTAARA) : public *EXCLUDE, le groupe JOBIGRP en *CHANGE, l'utilisateur JOBIUSER en *USE.
Écran 5250 Droits sur un objet DTA3, détail des droits sur les données : JOBIGRP lecture, ajout, mise à jour, suppression, exécution ; JOBIUSER lecture et exécution
Avec F11 : le détail des droits sur les données. *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 :

L'ordre de vérification des droits Le système vérifie dans l'ordre : le chemin rapide, le droit spécial *ALLOBJ de l'utilisateur, son droit sur l'objet, son droit dans la liste d'autorisation, le *ALLOBJ des groupes, les droits des groupes sur l'objet, les droits des groupes dans la liste, le droit public, et enfin les droits adoptés. Il s'arrête au premier droit trouvé, même insuffisant, sauf pour les droits adoptés. 1. Le chemin rapidedroits stockés dans l'objet : propriétaire, groupe principal, public2. *ALLOBJ de l'utilisateur3. Droit de l'utilisateur sur l'objetpropriétaire ou droit privé4. Droit de l'utilisateur dans la listesi une liste d'autorisation protège l'objet5. *ALLOBJ des groupes6. Droits des groupes sur l'objetcumulés sur tous les groupes7. Droits des groupes dans la liste8. Droit publiccelui de l'objet, ou de la liste si *AUTL9. Droits adoptésdu propriétaire du programme en cours
D'après IBM, Security reference, « How the system checks authority ». En bleu clair l'utilisateur, en violet ses groupes, en bleu le public, en rouge les droits adoptés.
Le système s'arrête au premier droit trouvé, même insuffisant. Seuls les droits adoptés peuvent encore compléter. Conséquence : un droit privé donné à un utilisateur masque celui de son groupe. Si l'utilisateur a *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 :

EssaiObjet et droitsActionRé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 *USE ne permet pas de modifier.
  • Essai 5 : *CHANGE modifie le contenu, mais ne supprime pas l'objet (CPF2189).
  • Essai 9 : une table SQL est un fichier comme les autres. Avec *USE on 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.

Écran 5250 Description de bibliothèque JOBIPRF : droits pour objets créés *SYSVAL
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 CRTAUT d'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

GRTOBJAUTDonner un droit sur un ou plusieurs objets.
RVKOBJAUTRetirer un droit.
EDTOBJAUTModifier les droits d'un objet à l'écran.
DSPOBJAUTAfficher les droits d'un objet.
CHGOBJOWNChanger le propriétaire d'un objet.
CHGOBJPGPChanger le groupe principal d'un objet.
GRTUSRAUTDonner à un utilisateur les mêmes droits privés qu'un autre.
CHGLIBChanger le droit par défaut des nouveaux objets d'une bibliothèque (CRTAUT).
WRKOBJPVTLes objets sur lesquels un profil a des droits privés.
WRKAUTLes droits d'un objet de l'IFS ; CHGAUT les modifie.

À retenir

  • Il faut un droit sur la bibliothèque et sur l'objet.
  • *USE lit, *CHANGE modifie le contenu, *ALL gère l'objet ; *EXCLUDE interdit.
  • 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 :

  1. 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.
  2. 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.