Berechtigung einer view

[Pikachu]

Prüfe mal die Einstellung "Berechtigung für neue Objekte" der Bibliothek, in der die Sicht erstellt wird.

Der Ersteller eines Objekts sollte eigentlich die persönliche Berechtigung *ALL für das von ihm erstellte Objekt bekommen und dadurch das Objekt selbst auch löschen dürfen.

[Robi]

Ok,
Naming ist *sys
Berechtigung für neue Objekte steht auf *sysval
QCRTAUT auf * change
(passt ja alles irgendwie nicht nicht)

Das mit dem GRANT TABLE ist auch noch nicht perfekt.
Hier sind alle OBJ mit einer Berechtigungsliste geschützt.
Das geht anscheinend mit dem GRANT TABLE nicht.
Aber damit kann ich mir wenigstens selber Berechtigung geben um dann ein CL hinterher zu schieben
Robi

[BenderD]

... auf eine Table sollte man normalerweise nicht zugreifen!!! sondern immer nur über Views - und wenn man für die Grants vergibt, werden die erforderlichen Rechte an der Table mitgesetzt.

D*B

[Robi]

@Dieter
diese View ist die ERSTE View, die in der Firma jemals erstellt wurde.

Und die knallt prompt, weil die Berechtigung nicht so steht wie sie soll ( auf einer Berechtigungsliste)

Da werd ich es schwer haben, das als neuen Standard zu etablieren

[BenderD]

... das ist mir durchaus Ernst!!! Das galt auch für DDS erstellte PFs und LFs - nie auf die PF direkt zugreifen (wg. Entkoppelung Datenbank und Anwendung)

D*B

@Dieter
diese View ist die ERSTE View, die in der Firma jemals erstellt wurde.

Und die knallt prompt, weil die Berechtigung nicht so steht wie sie soll ( auf einer Berechtigungsliste)

Da werd ich es schwer haben, das als neuen Standard zu etablieren

[Robi]

Also ...
Anschl. ein CL aufrufen ist 'unglücklich' ( wer denkt daran)

Also habe ich in in der Source
GRANT ALL ON AKTENJ01 TO Myprofile;
GRANT ALL ON AKTENJ01 TO EDVProfil;

eingefügt.

Ich habe nun alle Berechtigungen, EDV-Leiter nicht.
Objektberechtigung bei beiden: USER DEF
EDV hat am Objekt nur Opr, Ändern und Ref.
und an den Daten nur Lese.
Ich hab Lese und Ausf. sowie Opr, Verw, Exist., Ändern und Ref.

*PUBLIC (den verändere ich nicht) hat Lese + Ausf. bzw nur Opr

Was muß ich tun, um dem EDV-Leiter ein echtes ALLl zu geben

Robi

[Fuerchau]

SQL unterstützt das Berechtigungskonzept Berechtigungsliste leider nicht.
Hier ist der normale GRTOBJAUT erforderlich.
Wenn die Lib entsprechend mit Berechtigungsliste geschützt ist, benötigt man keine speziellen Berechtigungen an den einzelnen Objekten. Man kann dann PUBLIC alle rechte geben. Es kommen eh nur die User dran, die für die Lib berechtigt sind sowie die *ALLOBJ-User.

Ab wann die DB2/400 mal Rollen unterstützt müsste Birgitta beantworten können.

[BenderD]

... normalerweise hat man ein Erstellunsscript, das man mit RUNSQLSTM und da kann man auch einen GRTOBJAUT per stored procedure call auf QCMDEXC hinterherdüsen.

D*B

Also ...
Anschl. ein CL aufrufen ist 'unglücklich' ( wer denkt daran)

Also habe ich in in der Source
GRANT ALL ON AKTENJ01 TO Myprofile;
GRANT ALL ON AKTENJ01 TO EDVProfil;

eingefügt.

Ich habe nun alle Berechtigungen, EDV-Leiter nicht.
Objektberechtigung bei beiden: USER DEF
EDV hat am Objekt nur Opr, Ändern und Ref.
und an den Daten nur Lese.
Ich hab Lese und Ausf. sowie Opr, Verw, Exist., Ändern und Ref.

*PUBLIC (den verändere ich nicht) hat Lese + Ausf. bzw nur Opr

Was muß ich tun, um dem EDV-Leiter ein echtes ALLl zu geben

Robi

[B.Hauser]

da kann man auch einen GRTOBJAUT per stored procedure call auf QCMDEXC hinterherdüsen.

D*B

... oder ab Release 6.1 den CL-Befehl direkt im Skript mit führendem CL: hinterlegen.

Birgitta

[Fuerchau]

Scripte mit RUNSQLSTM sind meines Erachtens die unsicherste Methode da man die einzelnen SQL's leider nicht überwachen kann.
Beim 1. Fehler wird abgebrochen.
Wenn dann auch noch CL-Befehle dazukommen ...

[BenderD]

... deswegen lässt man die mit Commit düsen, wenn man das dann per SBMJOB macht, werden die bei korrekter Handhabung sogar automatisch zurück gesetzt.

D*B

Scripte mit RUNSQLSTM sind meines Erachtens die unsicherste Methode da man die einzelnen SQL's leider nicht überwachen kann.
Beim 1. Fehler wird abgebrochen.
Wenn dann auch noch CL-Befehle dazukommen ...

[Robi]

@Fuerchau
sehe ich ähnlich, ist aber praktikabel

@Birgitta
ist nur V5R4 (kannte ich auch noch nicht)

@Dieter
Prima, danke
call qcmdexc('grtobjaut ...', 52) im sql-script kannte ich nicht.
Funktioniert aber, Danke