Mythe N° 4 : autorité spéciale *ALLOBJ

 (Si vous attribuez *ALLOBJ directement à l’utilisateur, l’algorithme de vérification d’autorité IBM i reconnaîtra toujours le *ALLOBJ de l’utilisateur et n’ira jamais plus loin pour vérifier si l’utilisateur a été exclu d’un fichier ou d’un autre objet.) Malheureusement, le fait d’attribuer *ALLOBJ au groupe de l’utilisateur procure une fausse impression de sécurité. Oui, l’utilisateur recevra le message « Not authorized to object xxx » s’il essaie d’accéder directement à un objet duquel il a été exclu. Le problème est que tout ce que l’utilisateur doit faire pour contourner ce blocage est de soumettre un job à exécuter comme un profil qui n’a pas été exclu de l’objet. Et ce n’est que l’un des modes de contournement. Il y a tout simplement trop d’objets desquels vous devriez omettre l’utilisateur, pour couvrir toutes les méthodes d’accès alternatives. Vous ne seriez jamais sûr de les avoir couvertes toutes. De plus, vous devriez passer le système au peigne fin après chaque mise à niveau pour découvrir les éventuelles nouvelles méthodes introduites par la nouvelle release. Admettez donc que, quand vous attribuez l’autorité spéciale *ALLOBJ à un utilisateur – au niveau de l’utilisateur du groupe – il pourra accéder à tout objet sur le système.