PDA

View Full Version : Problem mit Zugriffen im IFS



Seiten : [1] 2

69sky
13-02-09, 10:17
Hallo Gemeinde,

ich hab ein Problem mit der Rechtevergabe im Integrated File System, genauer im Root.
Hab schon einiges hier im Forum über die Rechtevergabe gelesen aber eine Lösung für mein Problem konnte ich noch nicht finden.

Im Root liegt ein Verzeichnis wo 3 Berechtigungen eingetragen sind. Dies Problem betrifft nicht nur diesen Ordner sondern wie ich festgestellt habe alle Ordner im IFS/Root

*public auf *exclude
USRGRP1 (Gruppenprofil) auf *exclude
USRGRP2 (Gruppenprofil) auf *RWX

Nur die User die als zusätzliches Gruppenprofil USRGRP2 haben sollten somit auf diesen Ordner zugreifen können. Aber genau dies ist nicht der Fall. Jeder User kann auf die Ordner im IFS zugreifen nicht nur die Gruppe USRGRP2 :eek: Erst wenn ich den User explizit auf *exclude setze kann er nicht mehr darauf zugreifen.

Eines muss man noch bei uns wissen, alle User haben aus bestimmten Gründen das USRGRP1 Gruppenprofil in Ihrem Profil. Dies beinhaltet *allobj (wir wissen das egtl. nur der SECOFR das haben sollte, aus bestimmten Gründen mussten wir das damals aber so machen). Allerdings habe ich ja USRGRP1 auf *exclude gesetzt, also dürfte hier *allobj nicht ziehen, oder?

Andere Überlegung: Spielt die Rechtevergabe auf „/“ eine Rolle. Hier hat *public und auch USRGRP1 (die mit den *allobj) *rwx. Wenn ich die Rechte aber in meinem Ordner angebe, sollten diese Berechtigungen aber doch egal sein, oder?

Danke vorab für die Hilfe… bastel schon seit gut 3 Std. an dem Problem rum :(

Sky

Fuerchau
13-02-09, 10:20
Benutzer mit *ALLOBJ können NICHT ausgeschlossen werden.
Schließlich besagt eben *ALLOBJ eben alle Objekte und nicht nur ein paar.

69sky
13-02-09, 10:29
Können Sie auch nicht ausgeschlossen werden wenn Sie wie hier Ihr *allobj nur über ein Gruppenprofil bekommen?

Würde also heißen, wenn ich den Usern *allobj nicht wegnehmen könnte (aus welchen Gründen auch immer), ich jeden meiner 50 User die nicht auf das Verzeichniss zugreifen sollten in den Berechtigungen eintragen müsste und auf *exclude stellen?

Ufff….. :mad:

Fuerchau
13-02-09, 11:49
Hat ein User *ALLOBJ kann er auch nicht explizit ausgeschlossen werden (was ja durch PUBLIC schon gewährleistet wäre).

Du kannst den Usern nur *ALLOBJ entziehen um dieses Problem zu lösen.

Fuerchau
13-02-09, 11:56
Nachtrag:
*ALLOBJ unterläuft sämtliche Berechtigungskonzepte.

Wenn ich *ALLOBJ habe kann ich mir auch nachträglich noch *SECADM und alles andere selber berechtigen, da ich auch das Recht auf QSECOFR habe.

69sky
13-02-09, 12:09
Vielen Dank für Deine Antwort Fuerchau... werden jetzt mal sehen was wir hier am besten machen!

69sky
13-02-09, 12:13
Hat ein User *ALLOBJ kann er auch nicht explizit ausgeschlossen werden (was ja durch PUBLIC schon gewährleistet wäre).

Du kannst den Usern nur *ALLOBJ entziehen um dieses Problem zu lösen.

Hmm, das ist jetzt seltsam! Habe einen User explizit mit *exclude angegeben und schon kann dieser nicht mehr auf dieses Verzeichnis zugreifen (obwohl er auch Mitglied in einem Gruppenprofil ist das *allobj hat).

Fuerchau
13-02-09, 12:32
Das mit dem Gruppenprofil habe ich nicht gelesen, sorry.

Insoweit stimmt es schon.
Aber wenn mein Gruppenprofil *ALLOBJ hat, kann ich mir (mit ein bisschen Aufwand) auch selber *ALLOBJ verpassen.

pwrdwnsys
13-02-09, 14:11
Um das wirklich sauber zu lösen, müssten die Exit-Points des Betriebssystems bemüht werden. Dort wird bei jedem Zugriff dann ein (zu erstellendes!) Programm aufgerufen, welches den Zugriff auf diese Weise beschränkt.

Generell sollte - wie angemerkt - die Vergabe von *ALLOBJ restriktiv gehandhabt werden. Wenn das jeder User hat, kann man die Maschine eigentlich auch gleich mit Security Level 10 laufen lassen :(

Gruß Karsten

Zerberus77
18-02-09, 09:45
Hallo 69sky,

hier findest du die Antwort, warum der User Zugriff hat, bis du ihn explizit auf *EXCLUDE setzt:

IBM System i Support: Software Technical Document : 4294150 (https://www-912.ibm.com/s_dir/slkbase.NSF/1ac66549a21402188625680b0002037e/0c75a7c490ff93c9862565c2007d2fe6?OpenDocument)

MfG
Zerberus