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 !