[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Oct 2003
    Beiträge
    107

    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

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Du benötigst die Berechtigungen "*RX" für "/usr/sap/edi".
    Das hat mit der Freigabe "rootbin" nichts zu tun.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Oct 2003
    Beiträge
    107
    Hallo,

    danke für die Antwort.

    Auf dem Verzeichnis liegen folgende Berechtigungen:

    PHP-Code:
    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".

    PHP-Code:
    FreigabenameEDI
    Pfadname
    : /usr/sap/edi 

  4. #4
    Registriert seit
    Aug 2001
    Beiträge
    2.644
    Zitat Zitat von cs400_de Beitrag anzeigen
    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

  5. #5
    Registriert seit
    Oct 2003
    Beiträge
    107
    Zitat Zitat von holgerscherer Beitrag anzeigen
    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

  6. #6
    Registriert seit
    Aug 2001
    Beiträge
    2.644
    Zitat Zitat von cs400_de Beitrag anzeigen
    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

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Jun 2001
    Beiträge
    727
    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.

  9. #9
    Registriert seit
    Oct 2003
    Beiträge
    107
    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 Zitat von Sven Schneider Beitrag anzeigen
    Im /(Root) würde ich eh keine Dateien ablegen, alle darunterliegenden Verzeichnisse bzw. Dateisysteme lassen sich schützen, wie bereits durch Fuerchau beschrieben.

  10. #10
    Registriert seit
    Jun 2001
    Beiträge
    727
    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.

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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 !
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Jun 2001
    Beiträge
    727
    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.

Similar Threads

  1. Berechtigungen im IFS zuweisen
    By ChrisX in forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 03-12-07, 13:07
  2. Allgemeine Berechtigung für Jobs ... IFS Ordner ...
    By bode in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 30-10-06, 12:10
  3. Datei im IFS auf iSeries verschlüsseln
    By jo400 in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 21-10-06, 18:57
  4. Windowstabelle wird im IFS in CCSID 1252 erstellt
    By umeis in forum NEWSboard Windows
    Antworten: 3
    Letzter Beitrag: 11-08-06, 13:45
  5. Umlaute werden im IFS zu Sonderzeichen
    By y-tom in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 29-05-06, 15:31

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •