View Full Version : CL Programm Berechtigungsproblem
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 ?
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
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.
Hallo TARASIK !
Nur um sicherzugehen ...
Was zeigt denn DSPPGM bei "Eigner", "Benutzerprofil" und "Übernommene Berechtigung verwenden" bei eurem Programm?
Gruß
Jürgen
holgerscherer
28-03-04, 00:51
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
29-03-04, 19:33
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/mpo071703-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
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.
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
30-03-04, 20:10
@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
@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.