CL Programm Berechtigungsproblem

[TARASIK]

Hallo Forum,
ich glaube wir haben ein Verständnisproblem:

ein Cl Programm wurde erstellt mit der Berechtigung des
Erstellers (QSECOFR). Das Programm wurde daraufhin
nochmals umgewandel mit USRPRF=*owner damit ein
normaler User Test dieses CL-Programm auch
ausführen kann. Dies scheiter aber an der Meldung
"CPFA09C" keine Berechtigung für Objekt.
In dem CL-Programm läuft ein cpyfrmimpf ab, welches
ein Temporäres Verzeichnis erstellt.
Die Meldung auf das Objekt ist "/QSYS.LIB/QRECOVERY.LIB/file/mbr"

Hat jemand eine Idee, wo unser Fehler ist ?

[Pikachu]

Hallo!

Sieh mal ins Jobprotokoll, da dürfte sicher folgende Meldung enthalten sein:

Nachrichten-ID . . . . . . . : CPI2119

Nachricht . . . : Parameterwerte für AUT und USRPRF wurden ignoriert.

Ursache . . . . : Die Parameterwerte für AUT und USRPRF wurden ignoriert, da REPLACE(*YES) angegeben war. Daher wurde das vorhandene Objekt als Berechtigungsquelle verwendet. Alle persönlichen und allgemeinen Berechtigungen, das Attribut USRPRF und das Attribut USEADPAUT wurden aus dem vorhandenen Objekt in das neue Objekt &1, Art *&3, in Bibliothek &2 kopiert.

...

Viele Grüße
Jürgen

[TARASIK]

Hallo Jürgen,
danke für den Beitrag. Es sieht so aus, wenn wir der Sache auf
der Spur sind. Ich habe bei der Midrange einen interessanten
Artikel gefunden, dass adopted Authority für das IFS nicht
gültig ist und irgendwie ist bei dem cpyfrmimpf das IFS mit
im Spiel (als Zwischendatei) und da genau wird der Hase
begraben sein.

[Pikachu]

Hallo TARASIK !

Nur um sicherzugehen ...

Was zeigt denn DSPPGM bei "Eigner", "Benutzerprofil" und "Übernommene Berechtigung verwenden" bei eurem Programm?

Gruß
Jürgen

[holgerscherer]

Hallo Tarasik,

beachte die Berechtigungen. Wie Pikachu schreibt, wenn Du ein Programm mit dem Parameter USER(*OWNER) versiehst, muss trotzdem jeder, der das Programm aufrufen soll, das *USE Recht auf das Programmobjekt haben. (Immer aufpassen, dass Du da kein Scheunentor aufreisst).

Andererseits solltest Du auch darauf achten, dass alle Pfade bzw. Bibliotheken und dortige Objekte mit entsprechender Berechtigung versehen sind. Wenn für das aufgerufene Programm der Owner = QSECOFR oder ein Benutzer mit *allusr ist, sollte das ein geringeres Problem darstellen.

Zur Not (wie geschrieben):
CHGJOB JOB(*) LOGCLPGM(*YES)
dann das Programm aufrufen und nachher ein DSPJOBLOG

-h

[Sven Schneider]

Artikel gefunden, dass adopted Authority für das IFS nicht
gültig ist und irgendwie ist bei dem cpyfrmimpf das IFS mit
im Spiel (als Zwischendatei) und da genau wird der Hase
begraben sein.

Wenn es um CPYFRMIMPF geht dann ist genau das dein Problem.
Sämtliche IFS-API'S (Posix/Unix-like File API'S) unterstützen kein adopted Authority.
Hier musst du mit einem Swap des Benutzerprofils arbeiten.
(Get Profile Handle (QSYGETPH) and Set Profile (QWTSETP) APIs )
Hier ein Artikel mit Bsp.
http://www.midrangeserver.com/mpo/mp...3-story02.html

Es gibt nur eine Ausnahme und dabei handelt es sich um die "alten" HFS-Api's.
Diese wirken aber nur auf QOPT und QDLS.
Ein CL-Verteter wäre CPYTOPCD.

Sven

[TARASIK]

Hallo Swen,
ja genau das ist unser Problem. Die adopted authority wird
im IFS nicht unterstützt. Habe bei Midrange das benötigte
Beispielprogramm gefunden. Danke auch an die anderen
welche sich meinem Problem gedanklich angenommen
haben.

[Fuerchau]

Das Problem mit der Berechtigung hatte ich auch.
Mein Programm (mit QSECOFR-Berechtigung) submitted dann zum Schluß einfach ein CPYTOSTMF als neuen Job mit USRPRF(QSECOFR).
Das geht allerdings nicht mit SBMJOB (lehnt IBM nunmal ab) aber mit ADDJOBSCDE !
Ich benötige dann auch nicht die API's QSYGETPH/QWTSETP.

[Sven Schneider]

@Fuerchau
Den Unterschied zwischen Job-Scheduler und SBMJOB kann ich so nicht nachvollziehen.

Ab SECLVL=40 benötigt der Benutzer, welcher einen Job für einem anderen Benutzer ausführen will und dafür den hinterlegten Benutzer in einer JOBD nutzt, zusätzlich *USE-Rechte am Objekt dieses Benutzerprofils !!!

Bei SECLVL=30 genügt *USE-Recht an der JOBD.
Rechte am in der JOBD hinterlegtem Benutzerprofil benötigt man nur zur Erstellungs-/Änderungszeit der JOBD, nicht jedoch zur Ausführungszeit !!!
(CRT/CHGJOBD Parameter USER)

Das gilt sowohl für das Einstellen eines JOBSCDE-Eintrags als auch für einen SBMJOB.
Oder anders ausgedrückt ein Job aus dem Scheduler wird immer zuerst mit dem Benutzer übergeben, welcher den Eintrag erstellt/geplant hat, ist also wie ein manueller SBMJOB.

Sven

[Fuerchau]

@Sven

Selbst mit der Berechtigung (USRPRF(*OWNER) für QSECOFR-PGM) wird ein SBMJOB mit USRPRF(QSECOFR) abgelehnt. Im Hilfetext der Nachricht steht eindeutig, dass QSECOFR nicht verwendet werden kann (warum auch immer diese Sperre besteht).

Der Trick mit ADDJOBSCDE ist, dass hier QSECOFR als USRPRF erlaubt ist. Wenn man nun als Datum und Zeit *CURRENT verwendet und als Häufigkeit *ONCE, wird der Job sofort submitted und ist aus der Liste der SCD-Job's auch wieder weg. Somit kann ich mit adopted Authority einen Job unter QSECOFR submitten.
Die einzige Einschränkung ist halt, dass ich ggf. die Bibliotheksliste mit angeben muss, da hier *CURRENT nicht funktioniert.

[Rincewind]

Hiho,

wenn ich mich richtig erinnere bezieht sich das Problem aber nur auf den QSECOFR Benutzer.. nicht auf andere Benutzer mit demselben Recht (z.b. haben wir einen eigenen Benutzer der auch Secofr und alle anderen Rechte hat) So kann man dies auch halbwegs gut umgehen.

Immer natürlich unter der premisse dass man weiss was man tut und welches Loch sich einem da bietet.

Rince

[Fuerchau]

Nun, das Problem mit der Berechtigung ist so eine Sache:

Habe ich als User die Berechtigung *ALLOBJ kann ich mir problemlos ALLE fehlenden Berechtigungen beschaffen. Einzige Voraussetzung: Entweder Kommandozeilenberechtigung (LMTCPB(*NO)) oder Zugang zum MAIN-Menü.

Sobald ich Zugriff auf ADDJOBSCDE habe, kann ich einen Job unter QSECOFR submitten, der einen CHGUSRPRF für mich dann durchführt.