ODBC Zugriff beschränken

[Robi]

Hallo *all,

wir müssen zu einer Variablen, von uns bestimmten Zeit, den ODBC zugriff auf Dateien einer bestimmten Bibliothek sperren.
(z.B. um Trigger an/ab zu hängen)
Der EXIT Point QIBM_QZDA_sql1 und 2, ggf INIT währe Ideal.
Anscheinend habe ich im Parameter jedoch keine Infos, auf welche Bibliothek der Zugriff versucht wird.

hat da jemand eine Idee ?
Danke Robi

[Fuerchau]

Am besten vergibst du die Berechtigung an der LIB mittels

GRTOBJAUT OBJ(MYLIB)
OBJTYPE(*LIB)
USER(*PUBLIC)
AUT(*EXCLUDE)

und anschließend wieder

GRTOBJAUT OBJ(MYLIB)
OBJTYPE(*LIB)
USER(*PUBLIC)
AUT(*USE)

Über die Exit-Points ist es ungleich komplizierter, da der SQL-String übergeben wird und der Dateiname bzw. Libname extrahiert werden muss.

Eine etwas teurere Lösung ist der Einsatz von Überachungssoftware (PCSACC/400) in der man die Zugriffe dann explizit steuern kann.

Die Selbstprogrammierung von Exit-Points kann sich da schon einige Monate hinziehen.

[BenderD]

Hallo,

gut gemeint, aber zu kurz gedacht. Berechtigungen an Objekten werden nur bei der Pointerauflösung geprüft, sprich in der Regel beim ersten Zugriff.
Die Änderungen an Objektberechtigungen erfordern zudem (und deshalb) bei Dateien z.B. exclusiven Zugriff, ähnlich wie bei Triggern. Die Zwischenschaltung von Berechtigungslisten heilt dies zwar, aber dann trifft erstens wieder.
Die Exit Points könnten zwar neue Zugriffe verhindern, aber bestehende Sperren bringen diese auch nicht zum Verschwinden.
Was habt ihr eigentlich genau vor, warum sollen die Trigger abgehängt werden? Oder reicht temporäres Deaktivieren, oder geht es um die Änderung von Trigger Programmen?

Dieter

[Robi]

Hi,
es geht, wie meistens, um Korrekturen die nach einem Softwareupdate von uns nötig sind. Es kommt leider vor, das trotz aller Tests fehlerchen in den Programmen sind oder manuelles tun in Verbindung mit 'ich hab gedacht das ...' ein Chaos anrichtet. Wir können per Programm unsere Zugriffe auf Dateien in einer Bibliothek verhindern, die Anwender wechseln dan in das Kunden-Datawarehouse und greifen über ODBC zu.
Wir krigen dann Trigger nicht runter (auch nicht inaktiv), können LF's nicht löschen und neu aufbauen oder PF's nicht mit chgpf umsetzen. Da die SQL-odbc zugriffe vom Kunden kommen sind sie mal mit, mal ohne BIB. Ein generelles verbieten (in abh. von einem Schalter) geht nicht, da ich diesen Schalter auch setzen würde(Std.-Software mit wahlfreien BibliotheksNamen) wenn ich in der Test-Bibliothek etwas mit Dateien mache.
noch ne idee ?
Danke Robi

[BenderD]

Hallo,

um Trigger temporär zu inaktivieren, oder zu verdecken, kann man im Trigger ein anderes Programm mit Durchreichen der Parameter aufrufen und die eigentliche Verarbeitung dort machen.
Dieses Programm hat dann die eigentliche Funktionalität. Wird es durch einen Dummy verdeckt, macht der Trigger nix, oder je nach PGM was anderes.
Änderungen an der PF oder so, erfordern mehr als den Trigger abklemmen, da hilft wohl nur ein ALCOBJ mit *EXCL anfordern und dann die Jobs aus dem WRKOBJLCK kippen.

Dieter

[Fuerchau]

Das geht am sinnvollsten dann wirklich mit einem Überwachungstool wie PCSACC/400.
In diesem können User zu Gruppen geordnet werden und die benötigten ODBC-Berechtigungen erteilt werden.

Ob die Lib angegeben ist oder nicht spielt dabei keine Rolle, da ja bei fehlender Lib die Bibliotheksliste gesetzt sein muss.
PCSACC/400 berechtigt immer die richtige Datei und Lib.

Für Wartungsarbeiten entzieht man dann halt temporär die Berechtigungen in der Gruppe, so dass kein Zugriff mehr erfolgen kann.

Das Tool ist zugegeben etwas teuer, erlaubt aber eine sehr genaue Berechtigungsvergabe, vor allen Dingen auf jeden SQL-Befehl (SELECT, UPDATE, INSERT, DELETE), da ja meistens nur SELECT's per ODBC erlaubt sind.
(Neben vielen weiteren Zugriffsüberwachungen !!!)

Die Objekt-Berechtigung reicht da in vielen Fällen nicht aus.