von Carol Woodbury
Mythos Nr. 1: Benutzer-Klasse
Beginnen möchte ich mit einer Besprechung des Attributs Benutzer-Klasse im Benutzerprofil. Die Benutzer-Klasse wird nie für den Abgleich der Zugriffsrechte verwendet. Ich wünschte, ich hätte einen Dollar für jedes Mal, wenn mich hierzu jemand gefragt hat und bei der Beschreibung der Situation gesagt hat: „Der Benutzer ist in der *SECOFR Benutzer-Klasse.“
Wenn es darum geht festzustellen, warum ein Benutzer nicht zugreifen kann oder aber auf ein Objekt zugreifen kann, auf das er eigentlich nicht zugreifen darf, dann kann man das Attribut Benutzer-Klasse getrost ignorieren. Welche Benutzer-Klasse eingestellt ist, spielt einfach keine Rolle; der Algorithmus, der die Zugriffsberechtigung checkt, fragt das Attribut Benutzer-Klasse gar nicht ab.
Der Benutzer könnte in der Benutzer-Klasse *USER sein und alle nur möglichen Berechtigungen haben oder er könnte der *SECOFR Benutzer-Klasse zugeordnet sein und über gar keine besonderen Berechtigungen verfügen.
Wenn jemand sich also in diesem Zusammenhang das Klassen-Attribut ansieht, kann das durchaus dazu führen, dass er von falschen Voraussetzungen ausgeht. Die Benutzer-Klasse wird nur verwendet, um als Default Wert den Arbeitsbereich des Benutzers festzulegen wenn es darum geht, welche IBM i Menü-Optionen der Benutzer sehen soll und um festzulegen, ob besondere Zugriffsrechte beim IPL des Systems eingestellt werden müssen zwischen dem Security Level 20 und einem höheren Security Level.
Mythos Nr. 2: Adopted Authority
Die meisten Leute wissen, dass die Adopted Authority durch das Einstellen eines Attributs in einem Programm zugewiesen wird. Das Problem ist jedoch, dass viele Leute in diesem Zusammenhang an das falsche Attribut denken. Die Adopted Authority hängt von zwei Programm-Attributen ab: Use Adopted Authority (USEADPAUT) und User Profile (USRPRF). Es ist – wenn man sich den Namen ansieht – ganz offensichtlich, warum die meisten Leute denken, der Parameter USEADPAUT habe die Kontrolle, aber das stimmt nicht. Die Kontrolle hat das Attribut USRPRF. Wenn USRPRF auf *USER – den Defaultwert – eingestellt wird, übernimmt das Programm nicht. Wenn USRPRF dagegen *OWNER enthält, dann übernimmt das Programm die Berechtigungsstufe des Programms Owner, wenn die Person, die das Programm aufruft, über keine ausreichende Berechtigung verfügt.
Aber was wird dann durch das Attribut USEADPAUT gesteuert? Hier möchte ich zunächst einmal feststellen, dass die Übernahme der Berechtigungsstufe durch ein Programm (i.e. USRPRF enthält *OWNER) dazu führt, dass diese Berechtigungsstufe auch für alle in Folge aufgerufenen Programme gilt. Der Parameter USEADPAUT steuert dann, ob ein solches Programm die Berechtigungsstufe, die es durch ein zuvor laufendes Programm erhielt, auch tatsächlich verwendet. Das ist die einzige Möglichkeit, um zu verhindern, dass die weitergereichte Berechtigung verwendet wird.
Mythos Nr. 3: Adopted Authority und dynamisches SQL
Weiter im Zusammenhang mit Adopted Authority – trifft es immer zu, dass alles was innerhalb eines Programms passiert oder initiiert wird, dessen Berechtigung übernimmt, wenn das Programmattribut von User Profile auf *OWNER eingestellt ist?
Nicht immer. Enthält das Programm dynamisches SQL, dann passiert das nicht, da dynamisches SQL keinen Zugriff auf die übernommene Berechtigung des Programms hat. Wenn Sie wollen, dass das SQL-Statement die Berechtigung übernimmt, müssen Sie das Attribut Dynamic User Profile auf *OWNER stellen, wenn Sie Ihr Programm kompilieren. Ich sage hier ausdrücklich „wenn“ im zeitlichen Sinne. Sie können die Attribute, die die Übernahme der Berechtigung steuern, entweder zu dem Zeitpunkt setzen, wenn Sie das Programm kompilieren wollen oder indem Sie den Befehl Change Program (CHGPGM) laufen lassen. Es gibt bedauerlicherweise kein Interface, das es ermöglichen würde, das Attribut Dynamic User Profile nach der Kompilierung zu ändern. Zu diesem Zweck müssen Sie immer rekompilieren.
Mythos Nr. 4: ALLOBJ Sonderberechtigung
Hier befasse ich mich mit dem Parameter *ALLOBJ und der Sonderberechtigung. In manchen Unternehmen bin ich auf den Fall gestoßen, dass dem Gruppenprofil eines Benutzers *ALLOBJ zugewiesen wurde und dann sollte der Zugriff auf die verschiedenen Dateien und Befehle durch *EXCLUDE gesteuert werden. Man war der Meinung, die Berechtigungen des Benutzers auf diese Weise kontrollieren zu können.
Tatsächlich jedoch wird der IBM i Algorithmus, der die Zugriffsberechtigung checkt, sobald er direkt beim User auf *ALLOBJ stößt, gar nicht weiter prüfen, ob bei diesem Benutzer eventuell ein Ausschluss für eine Datei oder ein Objekt eingegeben wurde.
Noch nicht Abonnent? Sonderaktion nutzen.
Ähnliche Artikel:
