-
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
Zitat von Sven Schneider
Im /(Root) würde ich eh keine Dateien ablegen, alle darunterliegenden Verzeichnisse bzw. Dateisysteme lassen sich schützen, wie bereits durch Fuerchau beschrieben.
-
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.
-
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 !
-
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.
-
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.
Similar Threads
-
By ChrisX in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 03-12-07, 12:07
-
By bode in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 30-10-06, 11:10
-
By jo400 in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 21-10-06, 17:57
-
By umeis in forum NEWSboard Windows
Antworten: 3
Letzter Beitrag: 11-08-06, 12:45
-
By y-tom in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 29-05-06, 14:31
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks