IFS Freigaben berechtigen

[Fuerchau]

Hierzu muss man gerade im IFS die Unterschiede zwischen *RWX und den Objektrechten betrachten (Unix kennt nur RWX für Eigner, Gruppe und Rest der Welt, Public eben).

Das IFS beginnt generell bei "/" und ist über den OpsNav ggf. als Root freigegeben.
Diese Freigabe sollte man auf jeden Fall sehr einschränken (insbesonders wenn das Gast-Profil aktiv ist), da man über Root sich schon mal durchhangeln kann (vor allem QSYS.LIB).

Am Besten entfernt man diese sogar !!!

Über den OpsNav (oder API-Call) können nun einzelne Pfade des IFS freigegeben werden:

/Home/MyPrf => MyPrf
/Home/YourPrf => YourPrf
usw.

Erreichbar sind diese dann über
\\MySystem\MyPrf
\\MySystem\YourPrf

Die Verschachtelungstiefe ist hier fast unbegrenzt.

Nun kommen wir zu den Berechtigungen:

Berechtigungen beginnen immer von Oben nach Unten, egal wie die Freigabe denn nun tatsächlich lautet.

Habe ich auf "/" keine Leserechte, komme ich auch an Home oder gar Home\MyPrf nicht dran.

Auf Verzeichnissen gibt es noch die X-Berechtigung (aus Unix eXecute).
Diese gilt um einen CD/CHDIR in dieses Verzeichnis zu machen.
Dies gilt nicht, wenn ich einen Namen voll qualifiziert (also von oben an) angebe.

Kommen wir nun zu den Einzelberechtigungen:

Das IFS kennt keine Vererbung eines Owner-Programmes.
Die Standard-Berechtigung für neue Objekte ist generell:
*PUBLIC *EXCLUDE
Creator *RW(X)
Wobei Creator das erstellende Benutzerprofil ist.

Was auffällt ist, dass die sog. OBJAUT vollkommen fehlen !

Dies führt sogar dazu, dass ich zwar ein MKDIR aber keinen RMDIR machen kann.

Streamfiles kann ich zwar erstellen, schreiben, lesen, zurücksetzen, aber nicht mehr löschen.

Um dieses tun zu können, muss ich nach Erstellung eines IFS-Objektes noch einen CHGAUT hinterherjagen, was natürlich über den Windows/Linux-Client nun überhaupt nicht geht.

Hier kommen nun die Verzeichnisrechte hinzu.
*R = Verzeichnis lesen
*W = neue Objekte erstellen
*OBJEXIST = Löschen dieses Objektes
*OBJMGT = Verwaltung
*OBJALTER = Verändern (e.G. Rename)
*OBJREF = Referenz (Link z.B. aus DB2)

Steht auf dem Verzeichnis z.B. *PUBLIC *RWX *ALL, kann der Besitzer des neuen Objektes und auch jeder andere auch eben Löschen.

Wie Schütze ich also Verzeichnisse gegen Fremdzugriffe ?
Klar: *PUBLIC *EXCLUDE !

Eben leider so nicht ausreichend, da dem Eigner eben die OBJAUT's fehlen und somit ein Löschen (*OBJEXISTS) nicht möglich ist.

Nun kommt jedoch die Zusatzberechtigung je Profil ins Spiel.
Neben Public kann ich natürlich jeden einzelnen User mit den benötigten Rechten eintragen.
Allerdings muss ich das dann jeweils auch für die untergeordneten Verzeichnisse machen.

Alles ehr mühsam.

Hier hilft jedoch eine AUTL (Autorisierungsliste) !
Klar, kennen wir vom Rest der Welt, ähm, Libs.

Beim IFS hat diese jedoch eine kleine Besonderheit.
Denn in dieser AUTL gibt es auch einen *PUBLIC-Eintrag.

Dieser ist jedoch nicht zu verwechseln mit dem *PUBLIC des IFS-Objekts !!!

Da in der AUTL ja nur Objektrechte und keine *RWX-Rechte vergeben werden können, ist genau hier die Lösung:

Per AUTL wird jeder User für dieses Verzeichnis eingetragen und Achtung: *PUBLIC *CHANGE !

Auf dem IFS-Verzeichnis gilt weiterhin *PUBLIC *EXCLUDE und somit eine Sperre für alle nicht berechtigten User.
Duchr *PUBLIC *CHANGE in der AUTL erhält aber jeder benannte User den Zugriff auf das Verzeichnis und, oh Wunder, durch eben dieses *PUBLIC *CHANGE auch die Objektrechte !

So kann ich nun gezielt durch AUTL's die Verzeichnisse gegen unberechtigten Zugriff schützen, und

nicht vergessen "root" als Freigabe entfernen !

[Sven Schneider]

Das IFS beginnt generell bei "/" und ist über den OpsNav ggf. als Root freigegeben.
Diese Freigabe sollte man auf jeden Fall sehr einschränken (insbesonders wenn das Gast-Profil aktiv ist), da man über Root sich schon mal durchhangeln kann (vor allem QSYS.LIB).

Ein Netserver-Freigabe auf / (Root) würde ich niemals !!! einrichten und ist per default auch nicht eingerichtet.
Auf einem Wintel-Fileserver macht das ja auch keiner.

Trotzdem komme ich an die / (Root) über folgende Funktionen.

- im Opsnav direkt über Dateisysteme
- über ftp
- über CMD WRKLNK etc.
- über Client Network-Redirector des Client Access V3RxMx
- über eine andere i5 und Dateisystem Qfilesrv.400
- iSeries Access API's
- java Toolbox Klassen

Der Opsnav greift über API's auf das IFS zu, analog dem Client Network-Redirector von CA V3 bzw. Dateisystem Qfilesrv.400.
D.h. er benutzt nicht die Freigaben bzw. Funktionen des Netservers (SMB) für Zugriffe auf IFS-Objekte.

[Fuerchau]

Für alle Remote-Zugriffe gibts ja den Schutz über die Registrierungspunkte (WRKREGINF), aber da macht sich ja selten jemand die Mühe.

Um eine Schutz vor externen Zugriffen (als Netz) auf die AS/400 zu haben, empfielt sich die Programmierung dieser User-Exits.
Wer da ein wenig Geld in die Hand nimmt, kann sich einen sehr guten Schutz mit PCSACC/400 erkaufen.

In diesem kann man gerade, was das IFS betrifft, ganz genau defineiren, auf welche Verzeichnisse zugegriffen werden darf.

Lokal auf der AS/400 kann ich durch sinnvolle Berechtigungssteuerung auf CMD-Ebene (bzw. LMTCPB des USRPRF's) den Schutz erreichen.

Dies gilt für alle oben genannten Zugriffswege.