PDA

View Full Version : Prozedur als bestimmter Benutzer starten



hs
24-11-04, 09:49
Gibt es eine Möglichkeit, dass der Benutzer A einen Job startet, diesen aber mit dem Profil von Benutzer B ausführt.

Ich kenne diese Möglichkeit nur beim Jobsceduler, da gibtb es einen Parameter "USER".

Das Vererben von Berechtigungen (*OWNER bei Wandeln) nutzt mir an dieser Stelle nichts.

Vielen Dank für die Info
HS

Fuerchau
24-11-04, 09:56
Das geht auch über den Parameter USER(B) !
Aber: User A benötigt die Berechtigung an User B, da der SBMJOB sonst abgelehnt wird.

Umgehung ist auch hier wieder *OWNER des PGM's. Wenn der Eigner des Programmes Berechtigung an User B hat, kann User A einen Job für User B submitten.

hs
24-11-04, 10:01
Hallo Fuerchau,

das Programm wird interaktiv mit CALL aufgerufen, nicht mit SBMJOB.

Gruß
HS

BenderD
24-11-04, 11:26
Hallo,

dann bleiben noch die Security APIs. die sowas können - was soll den Zweck der Übung sein?

Dieter Bender


Hallo Fuerchau,

das Programm wird interaktiv mit CALL aufgerufen, nicht mit SBMJOB.

Gruß
HS

hs
24-11-04, 12:25
hmm...

das hört sich kompliziert an.

Der Hintergrund ist folgender:

Es gibt einen Benutzer X, bei dem im USRPRF eine Startprozedur hinterlegt ist, welche ein bestimmtes Programm startet.

Wenn andere Benutzer Y dieses Programm verwenden wollen, dann müssen sie sich in einer zweiten Sitzung als dieser Benutzer X anmelden.

Ich möchte dies aber dahingehend vereifachen, dass die Benutzer Y mit ihrem eigenen Namen das Prog. starten können. Da das Programm aber mit Benutzer Y nicht funktioniert, muss dies eben in einer Art "Benutzer X - Umgebung" gestartet werden.

Hoffe es war einigermaßen verständlich.

Gruß
HS

Fuerchau
24-11-04, 13:32
Dies geht so nicht ganz.
Die Umgebung bleibt Benutzer Y, das Programm muss mit *OWNER des Users X (chgpgm, crtxxxpgm) erstellt werden.
Dann läuft das Programm mit den Berechtigungen des Users X und Y.

Warum nützt dieses "Vererben" nicht ?

BenderD
24-11-04, 14:40
hmmm...

das hört sich einfach an:
aus einem Menü oder per CL
TELNET localhost RMTUSER und RMTPWD mitgeben
dann muss man nur noch dafür sorgen, dass beim verlassen ENDCNN(*YES) mitgegeben wird.

mfg

Dieter Bender


hmm...

das hört sich kompliziert an.

Der Hintergrund ist folgender:

Es gibt einen Benutzer X, bei dem im USRPRF eine Startprozedur hinterlegt ist, welche ein bestimmtes Programm startet.

Wenn andere Benutzer Y dieses Programm verwenden wollen, dann müssen sie sich in einer zweiten Sitzung als dieser Benutzer X anmelden.

Ich möchte dies aber dahingehend vereifachen, dass die Benutzer Y mit ihrem eigenen Namen das Prog. starten können. Da das Programm aber mit Benutzer Y nicht funktioniert, muss dies eben in einer Art "Benutzer X - Umgebung" gestartet werden.

Hoffe es war einigermaßen verständlich.

Gruß
HS

Fuerchau
24-11-04, 15:02
Einfacher gehts mit den API's:

Get Profile Handle (QSYGETPH) API
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QSYGETPH.htm
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/qsygetphe.htm

sowie
Set Profile Handle (QWTSETP, QsySetProfileHandle) API
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QWTSETP.htm

Aber Achtung:
Das Kennwort muss ja irgendwoher im Klartext kommen (es sei denn das Profil hat kein Kennwort) und die API's sind mit Auslieferung des OS auf Berechtigung *PUBLIC *EXCLUDE.
Wird kein Kennwort benötigt (*NOPWDCHK) wird die Berechtigung am Profil benötigt.

Um diese also verwenden zu können, muss das Programm die benötigte Berechtigung mitbringen (Eigner QSECOFR und *OWNER).

Aber nun gibt es noch folgende Probleme:

- Ab dem Setzen des Profils erhält der Benutzer die VOLLE Berechtigung des neuen Users.
- Alle Druckausgaben laufen unter dem Namen des neuen Users.
- Durch Systemanfrage 2 könnte das Programm unterbrochen werden und ab da bin ich nun der neue User

Das Programm muss also Systemanfrage 2 abfangen (sperren geht nicht) und natürlich wenn es fertig ist, das ursprüngliche Profil wieder herstellen (auch mittels Get/SetProfile) !!!