View Full Version : IFS Freigaben berechtigen
Sehr geehrte Damen und Herren,
Wir verwenden z.B. für EDIfact und noch andere Dinge bestimmte Verzeichnisse im IFS. Diese werden über die SAP Transaktion al11 sichtbar gemacht und dann werden Flatfiles mit den SAP R3 Standardmitteln auf dem Applikationsserver (also im IFS) abgelegt.
Will man nun von außen diese Files abholen, per ODBC oder per
Laufwerksfreigabe über den Netserver, benötigt man einen User und die entsprechende Berechtigung.
Bei mir gibt es z.B. die Freigabe "rootbin" auf '/' des iSeries Servers. Und dann gibt es die Freigabe "edi" auf '/usr/sap/edi' des gleichen Servers.
Ich habe nun einen User "EDIUSER" angelegt der Rechte auf auf die Freigabe "edi" und die darin enthaltenen Files hat.
Da aber auch noch eine Freigabe "rootbin" existiert, auf die dieser User keine Rechte haben sollte, habe ich den User dort mit *exclude eingetragen.
Wenn das *exclude in der Freigabe "rootbin" drin ist kann der
User "EDIUSER" sich nicht mehr mit dem netserver über den Windows Explorer verbinden, auch nicht auf die Freigabe "edi", die ja auf das Verzeichnis '/usr/sap/edi' geht.
Meine Frage ist wie kann ich denn IFS Freigaben oder Verzeichnisse spezifiziert berechtigen? Hat jemand einen Leitfaden?
mit freudlichen Grüßen
Carsten Schulz
Du benötigst die Berechtigungen "*RX" für "/usr/sap/edi".
Das hat mit der Freigabe "rootbin" nichts zu tun.
Hallo,
danke für die Antwort.
Auf dem Verzeichnis liegen folgende Berechtigungen:
Objekt . . . . . . . . . . . . : /usr/sap/edi
Daten- ----------Objektberechtigungen----------
Benutzer berecht. Existenz Verwaltung Änderung Referenz
*PUBLIC *RWX X X X X
Auf den Verzeichnis '/', also root ist auch *PUBLIC *RWX usw.
Setze ich jedoch den User "EDIUSER" auf dem Verzeichnis '/' mit *exclude, weil cih nicht möchte das er sich auf Root verbindet, lasse aber *public mit *rwx auf Root, dann ist ein "Netzlaufwerk verbinden" auf /usr/sap/edi nicht mehr möglich, obwohl er dort noch alle Rechte hat und auf diesem Verzeichnis auch eine eigene Freigabe liegt, nämlich "EDI". :confused:
Freigabename: EDI
Pfadname: /usr/sap/edi
holgerscherer
03-04-07, 17:21
Auf den Verzeichnis '/', also root ist auch *PUBLIC *RWX usw.
Setze ich jedoch den User "EDIUSER" auf dem Verzeichnis '/' mit *exclude, weil cih nicht möchte das er sich auf Root verbindet...
Das ist generell eine nicht so vorteilhafte Idee. IBM empfiehlt, für / (also IFS Stammordner) den Zugriff für *PUBLIC auf *RWX zu setzen - mein Favorit ist *RX.
Da fast alle wichtigen darunter liegenden Ordner eigene Dateisysteme sind (wie QSYS.LIB, QDLS, etc), sollte man hier die für *public passenden Rechte setzen. Auf /usr ist in der Regel sowieso ein Leserecht für alle sehr sinnvoll.
-h
Das ist generell eine nicht so vorteilhafte Idee. IBM empfiehlt, für / (also IFS Stammordner) den Zugriff für *PUBLIC auf *RWX zu setzen - mein Favorit ist *RX.
-h
Hallo Holger,
hallo ihr anderen Leser,
danke für Deine Antwort.
Wenn ich *public *RX für / setze, so habe ich doch das ganze System aufgemacht, außer da wo public wieder exculded ist, oder?
QSYS.LIB müsste doch dann auch komplett offen sein, oder greifen dann die OS/400 Berechtigungen?
Grüße
Carsten Schulz
holgerscherer
03-04-07, 22:17
Wenn ich *public *RX für / setze, so habe ich doch das ganze System aufgemacht, außer da wo public wieder exculded ist, oder?
Hallo Carsten,
/ sollte schon *RX für alle sein, ebenso wie QSYS.LIB (sonst hätten die User eh leichte Sorgen). Man sollte immer von "oben" nach "unten" denken - Objektsicherheit ist eine der Hauptregeln bei Security. Wenn QSYS.LIB *RX für alle ist, die darunter liegende MEINEDATA.LIB aber *EXCLUDE für *ALL und *RWX für XYZ, kann auch nur XYZ auf MEINEDATA zugreifen. Man sollte ja nicht überall eine vollautomatische Rechtevererbung bis auf den letzten Member / das letzte Objekt in der tiefsten IFS-Ebene verwenden.
Wie in der Teh-Werbung: "man kann, aber man muss nicht".
-h
Auf allen Ebenen greifen immer alle Objektberechtigungen.
Dies gilt für /QSYS.LIB genauso wie für alle anderen IFS-Objekte.
Fehlt eine *R bzw. *X-Berechtigung kann man eben an untergeordnete Ebenen nicht mehr herankommen.
Sicherlich ist es ein Hauptproblem, dass ich per IFS-Zugriffe zu ziemlich an alles herankomme, das ist aber von jeher so, da ein User nun für seine 5250-Programme eben auch diese Berechtigungen benötigt.
Einen Schutz bietet da nur eine API-Programmierung (siehe WRKREGINF), die durch Programme wie PCSACCESS/400 sehr gut abgedeckt werden.
Sven Schneider
12-04-07, 22:25
Wenn ich *public *RX für / setze, so habe ich doch das ganze System aufgemacht, außer da wo public wieder exculded ist, oder?
Weiterhin betrifft das nur die Zugriffe über iSeriesNavigator bzw. CMD-Umgebung in der 5250-Umgebung bzgl. des /(Root) Verzeichnisses und ggf. ftp Client-Zugriffe.
Der Zugriff per PC und SMB-Client geht ja nur, wenn ich eine Freigabe auf /(Root) einrichte.
Im /(Root) würde ich eh keine Dateien ablegen, alle darunterliegenden Verzeichnisse bzw. Dateisysteme lassen sich schützen, wie bereits durch Fuerchau beschrieben.
Leider kann der Netserver auf der I5 keine Berechtigungen auf Freigaben einrichten, wie z.B. bei einem Windows-Server.
Das stammt allerdings noch aus den Hinterlassenschaften der OS/2 bzw. Lanmanager Implementierung des Netserver.
Hallo,
heißt das, das es einen Unterschied zw. Root und den Verzechnissen darunter gibt, was die Berechtigungsregelungen im IFS angeht?
Das kann ich mir fast nicht vorstellen.
Grüße
Carsten Schulz
Im /(Root) würde ich eh keine Dateien ablegen, alle darunterliegenden Verzeichnisse bzw. Dateisysteme lassen sich schützen, wie bereits durch Fuerchau beschrieben.
Sven Schneider
16-04-07, 19:13
Hallo,
heißt das, das es einen Unterschied zw. Root und den Verzechnissen darunter gibt, was die Berechtigungsregelungen im IFS angeht?
Das kann ich mir fast nicht vorstellen.
Grüße
Carsten Schulz
Nein das heißt es nicht, d.h. warum sollte es hier Unterscheide geben.
Ich habe nur gesagt - ich würde keine Dateien im /(Root) ablegen, da dieses minimum *PUBLIC *RX haben sollte.
(Der Owner QSYS muss sogar *RWX haben, das nur am Rande)
Dafür gibt es Dateisysteme bzw. Unterverzeichnisse, welche ich entsprechend berechtigen kann.