Berechtigung einer view

[Robi]

Hi *all

Ich erzeuge mit runsqlstmt eine view.

CrtView MyView as ( select ... )

Diese wird mit der Berechtigung PUBLIC *USE erstellt.
Nun habe ich keine Berechtigung mehr, diese zu löschen

Beim runsqlstmt gibt es (verständlicher weise) keine Möglichkeit eine Berechtigungsliste zu setzen.

Aber wo ist dann eingestellt mit welcher Berechtigung die View erzeugt wird?
Und wie kann ich das ändern ?

Danke
Robi

[B.Hauser]

Berechtigungen für SQL Views (bzw. SQL Objekte) ordnet man mit dem SQL Befehl GRANT TABLE zu.

Der GRANT TABLE kann im gleichen Member wie der CREATE-Befehl hinterlegt werden und damit im gleichen RUNSQLSTM ausgeführt werden.

Um die Berechtigungen wieder zu entziehen wird REVOKE TABLE verwendet.

Welches Naming verwendest Du eigentlich?

Mit System-Naming wird ein Datenbanken-Objekt mit Public *CHANGE erzeugt, mit SQL-Naming im Public = *EXCLUDE. Wie die Berechtigung Public = *USE zustande kommt ist mir ein Rätsel.

Birgitta

[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 ...