Hot Tip – Ein Erfolg versprechender IFS Tipp: Authority Regeln – Das IFS unterstützt OS/400 bei der Interaktion mit anderen Betriebssystemen

von Mel Beckman

 

Die Berechtigungseinschränkungen innerhalb des IFS sind ein Thema, das gut verstanden sein will, wenn das IFS optimal mit traditionellen OS/400 Anwendungen zusammenarbeiten soll.

Das IFS verwendet eine Autorisierung im Unix-Stil, die über so genannte Permission Flags gesteuert wird, die für eine Datei oder ein Verzeichnis kollektiv die Bezeichnung „Mode of Access“ tragen. Drei unterschiedliche Berechtigungen stehen zur Verfügung: Read, Write und Execute. Die Berechtigung Execute hat zwei Bedeutungen. Für eine Datei bedeutet sie, dass diese Datei als Programm ausgeführt werden kann; für ein Verzeichnis, dass dieses Verzeichnis durchsucht werden darf.

In den meisten Fällen zeigt OS/400 diese Permission Flags symbolisch als *-Werte oder als eine 3 Zeichen umfassende Zeichenkette an. So beinhaltet *RX beispielsweise die Lese- und Ausführungsberechtigung, *X nur die Berechtigung zur Ausführung usw. Die Flags repräsentieren eine bit-Position in einer binären Zahl, die gelegentlich auch als dezimaler

Wert erscheinen kann, wenn sie von anderen Systemen (beispielsweise über FTP) angezeigt wird. Die binäre Position ist 1xx für den Read-Flag, x1x für den Write-Flag und xx1 für den Execute-Flag. Somit beinhaltet der dezimale Wert 5 (binär ‚101‘) die Lese- und Ausführungsberechtigung, der Wert 1 (binär ‚001‘) nur die Berechtigung zur Ausführung.

Es gibt drei Sätze von Permission-Flags: einen für den Eigentümer, einen für eine Eigentümergruppe und einen für den allgemeinen Zugriff (general public). Diese Berechtigungssätze werden über die Schlüsselworte *OWNER, *GROUP und *PUBLIC referenziert.

Probleme können immer dann auftreten, wenn ein Objekt von einem Berechtigungsbereich in den anderen kopiert werden soll. Um beispielsweise eine OS/400 Datei mit der Anweisung CPYTOSTMF in das IFS zu kopieren, ist für das OS/400 Objekt die Berechtigung *OBJMGT (Object Management) erforderlich, da die Anweisung CPYTOSTMF die Berechtigungsinformationen des Quellenobjektes (den Namen und die Berechtigungen des Eigentümers) auslesen muss, um diese Informationen entsprechend auf das zu erstellende IFS Objekt abbilden zu können. Liegt die geforderte Berechtigung nicht vor, kann die Anweisung CPYTOSTMF nicht erfolgreich ausgeführt werden.

iSeries Experten diskutieren zu ähnlichen Themen: suchbegriffe +IFS +Zugriff

Zugriff auf PC Netzwerk Zugriff auf QOPT Zugriff auf IFS ohne ClientAccess IFS und Benutzerrechte, etc. Zugriff auf Integrated File System der AS/400

jetzt in die Diskussion einsteigen!

Das IFS erfordert *RX Berechtigung für alle Verzeichnisse im gesamten Pfad zu einem Verzeichnis, das gelesen oder verändert werden soll. Für die Navigation zu einem Verzeichnis desselben Pfades mit der Anweisung CD oder der Funktion chdir() ist hingegen nur die Berechtigung *X erforderlich. Das bedeutet, dass eine Navigation zu einem Verzeichnis zwar möglich ist, sich dann aber herausstellt, dass die Berechtigung zum Lesen des Verzeichnisses oder zum Hinzufügen, Löschen oder Verschieben von Dateien fehlt. Selbst wenn man über die Berechtigung RWX (oder *ALL) für das Zielverzeichnis verfügt, sind die zuvor erwähnten Veränderungen nicht zulässig, solange keine *RX Berechtigung für alle Verzeichnisse in dem gesamten Pfad vorhanden ist.

Das IFS vergibt die Berechtigungen für neu erstellte Dateien und Verzeichnisse in einer merkwürdigen Weise, die von vielen Anwendern anfänglich als verwirrend empfunden wird. Das IFS übernimmt die Eigentümer- und Gruppennamen für ein neu erstelltes Objekt von den Werten, die für das Verzeichnis gelten, das dem Verzeichnis, in dem das Objekt letztlich erstellt wird, übergeordnet ist. Es werden also nicht, wie man erwarten würde, die Werte des Verzeichnisses verwendet, in dem das Objekt erstellt wird. Nur die *PUBLIC Berechtigungen werden von dem Verzeichnis übernommen, in dem das Objekts erstellt wird. Dieses Verhalten hat den unerwünschten Nebeneffekt, dass es möglich ist, Objekte in einem Verzeichnis zu erstellen, auf die man anschließend keine Zugriffsberechtigung mehr hat!

Wären diese Regeln konsistent, würde es sich lediglich um eine weitere Ebene von Restriktionen handeln, die man erlernen muss. Leider können einzelne Programme hier durchaus ein abweichendes Verhalten zeigen. So übernimmt CPYTOSTMF beispielsweise von einem OS/400 Quellenobjekt nur die Berechtigungsinformationen des Eigentümers. Gruppenberechtigungen oder Autorisierungen werden nicht übernommen und die *PUBLIC Berechtigungen werden auf den Wert 0 gesetzt (alle bits sind aus – entspricht *NONE). Auch Windows und Unix Programme, die über einen fernen Zugriff auf das IFS verfügen, folgen eigenen Regeln.

Der eigentliche Kern dieses Tipps ist, ein Verständnis für die grundsätzlichen Regeln und das Standardverhalten bei der Vergabe von Berechtigung im IFS zu erlangen. Eine Überprüfung, ob die letztlich vergebenen Berechtigungen den Erwartungen entsprechen, ist daher unerlässlich. Die meisten IFS Probleme resultieren aus nicht korrekt gesetzten Berechtigungen.

Nur die „Ersten Fünf“

Dies sind sicherlich nicht die einzigen Tipps für den Umgang mit dem IFS und ich will nicht behaupten, dass sie notwendigerweise die wichtigsten Tipps für jedermann sind. Aber mit diesen Tipps ist man recht gut ausgestattet, um aus dem IFS zusätzlichen Nutzen für die eigenen Anwendungen zu ziehen. Weitere fünf IFS Tipps sind für eine der nächsten Ausgaben geplant.