Übernommene Berechtigung verwenden - USEADPAUT

[Frank Hildebrandt]

Hallo,

ich möchte, dass meine Programme und Serviceprogramme mit 'Übernommene Berechtigung verwenden - USEADPAUT' gleich '*NO' kompiliert werden. Bei jeder Kompilierung habe ich im Programm bzw. Serviceprogramm den Wert '*YES' stehen und ich muss mit CHGPGM USRADPAUT(*NO) dieses wieder zurücksetzen. Gibt es da nicht etwas einfacheres und warum wird standardmäßig bei der Kompilierung '*YES' anstatt '*NO' verwendet. Meines Erachtens nach sollte es doch so sein, dass man zuerst die Tore geschlossen hält und dann explizit sagt dass der eine etwas darf.

Danke

Frank Hildebrandt

[Fuerchau]

Ggf. wurd der CMD-Default geändert (CHGCMDDFT) ?

[Frank Hildebrandt]

Hallo,

ich kann weder im Befehl CRTPGM noch im CRTSRVPGM einen Parameter USEADPAUT finden. Von daher kann es nicht sein, dass über CHGCMDDFT etwas geändert wurde.

Frank

[Josh]

Übernommene Berechtigung verwenden zieht doch meines Wissens
nur, wenn auch der Parameter USRPRF auf *OWNER steht.
Wenn ich mich nicht ganz grob irre, wo ist dann das Problem?

[Frank Hildebrandt]

Übernommene Berechtigung verwenden zieht doch meines Wissens
nur, wenn auch der Parameter USRPRF auf *OWNER steht.
Wenn ich mich nicht ganz grob irre, wo ist dann das Problem?

Das zieht auch dann, wenn der Parameter USRPRF auf *USER steht.

Frank

[Fuerchau]

Dazu muss man folgendes verstehen:

USRPRF(*USER): nur Berechtigung des angemeldeten Benutzers
USRPRF(*OWNER): ZUSÄTZLICH Berechtigung des Eigners

USEADPAUT(*YES): Berechtigung des AUFRUFENDEN Programmes berücksichtigen
USEADPAUT(*NO): NUR Berechtigung des aktiven Programmes verwenden

USEADPAUT ist daher weniger kritisch als USRPRF.
Betrachtet man also mal den Programmstack, werden die Berechtigungen von oben nach unten vererbt. Die Vererbung wird wird dann mittels USEADPAUT(*NO) unterbrochen und ab dieser Aufrufebene neu verwendet.

Man kann also USEADPAUT getrost vergessen, wenn man folgende Richtline einhält:
Ein Programm mit USRPRF(*OWNER) sollte ausschließlich für spezielle Aufgaben verwendet werden und selber wiederum keine anderen (ausser absolut notwendigen) Anwendungsprogramme (insbesonders Dialoge) aufrufen.

Beachte auch, dass bei keinem CRTxxxPGM der Parameter USEADPAUT vorhanden ist sondern nur der Parameter USRPRF !

[Frank Hildebrandt]

Danke für die Beiträge. Ich werde dann wohl so weiter verfahren wie bisher.

[BenderD]

Hallo,

wie wärs über Sysval QUSEADPAUT?

@Baldur: so ganz trivial ist das nicht, mit den *OWNER Programmen, da geht der Punk ab, wenn man ein Programm verdeckt und sich dann einen QCMD von einem Programm mit *OWNER QSECOFR aufrufen lässt...

mfg

Dieter Bender

Danke für die Beiträge. Ich werde dann wohl so weiter verfahren wie bisher.

[holgerscherer]

@Baldur: so ganz trivial ist das nicht, mit den *OWNER Programmen, da geht der Punk ab, wenn man ein Programm verdeckt und sich dann einen QCMD von einem Programm mit *OWNER QSECOFR aufrufen lässt...

LOL, das habe ich mal in einer älteren Anwendungssoftware bei einem Kunden gesehen (Software von einem externen Anbieter, individuell programmiert). Man konnte dort in jedem Bildschirm, der Auswahlen zuliess, eine 99 eingeben, und schon hatte man über USER(*OWNER) eine QCMD. War wohl mal zu Debugzwecken eingebaut worden, aber nie ausgebaut....

Wie ich dann 3 Minuten später feststellen durfte, war das eigentlich auch egal, die Kiste lief mit SecLvl 20.

-h

[Fuerchau]

@Dieter
Deshalb sag ich ja, nur spezielle Funktionen und nicht z.B. QUSCMDLN.