SET_COLUMN_ATTRIBUTE funktioniert nicht ?

[a.wojcik]

Hallo *all !
hat jemand schon die SQL Funktion "SET_COLUMN_ATTRIBUTE" ausprobiert ?
Da sollte man die Anzeigeberechtigung für ein Feld steuern können :
CALL SYSPROC/SET_COLUMN_ATTRIBUTE
('LIB', 'DATEI', 'FELD', 'SECURE YES')
Ich habe es für eine Datei angewendet, in der syscolumns2
SELECT TABLE_NAME , column_name, secure FROM syscolumns2
WHERE TABLE_SCHEMA = 'LIB' and secure <> 0
war mein Feld mit Status 1 zu sehen, aber den Inhalt des Felders kann man immer noch mit QRY oder SQL sehen.
Bei einer anderen Datei habe ich nach dem Aufruf der Funktion sogar eine böse Überraschung erlebt - die ganze Datei war nachher leer.

Grüße
a.wojcik

[Fuerchau]

Wozu soll die Funktion gut sein?
The SET_COLUMN_ATTRIBUTE procedure sets the SECURE attribute for a column so variable values used for the column cannot be seen in the database monitor or plan cache.
Wenn du Spalten für SQL/Query unsichtbar machen willst schaffst du das nur mit der Berechtigung:
*PUBLIC *EXCLUDE auf die PF/LIB.
Erstellen einer View in einer anderen Lib mit den sichtbaren Feldern.
Alles andere wird schwer bis gar nicht nachvollziehbar.

[B.Hauser]

Mit der Funktion SET_COLUMN_ATTRIBUTE kann man lediglich verhindern, dass die Werte im Klar-Text im Database Monitor und/oder Plan Chache angezeigt werden.
Man kann jedoch damit nicht die allgemeine Anzeigeberechtigung steuern.
Dazu benötigt man RCAC (Row and Column Access Control). Mit Spalten-Masken, die mit der Tabelle (bzw. der Spalte verklinkt werden), können die Inhalte für Benutzer sichtbar bzw. maskiert werden.

Auszug aus DB2 for i - Services Dokumentation:
SET_COLUMN_ATTRIBUTE:

The SET_COLUMN_ATTRIBUTE procedure sets the SECURE attribute for a column so variable values used for the column cannot be seen in the database monitor or plan cache.


Birgitta

[Fuerchau]

Wer schon mit der normalen Objektberechtigung auf Kriegsfuß steht, sollte sich gar nicht erst mit RCAC beschäftigen. Die setzt nämlich noch einen drauf und kann eine laufende Anwendung zum Absturz bringen.
Dazu bedarf es schon eines sehr guten DB-Designs mit ausschließlichen SQL-Zugriffen.

Die gute alte Objektberechtigung mit Views als Layer für externe Zugriffe ist hier erheblich einfacher und ebenso sicher.

[a.wojcik]

Tja, ich war schon einfach neugierig, ob die Funktion das macht, was ich dachte - z.B. ohne "alte" QRY's umzubauen, einige Felder (Preise ?) einfach in der Anzeige "verwischen" lassen ?

[Fuerchau]

Sobald man sowas wie RCAC einsetzen würde, kann Query nicht mehr funktioneren, wenn Spalten ausgeblendet werden.
Du kannst das ohne RCAC testen in dem du z.B. eine View erstellst und im RUNQRY dann diese statt der Originaldatei angibst (alternativ auch per OVRDBF).
Query meldet dann diverse Fehler und ggf. wird die Liste gar nicht mehr erstellt.

[B.Hauser]

Sobald man sowas wie RCAC einsetzen würde, kann Query nicht mehr funktioneren, wenn Spalten ausgeblendet werden.
Du kannst das ohne RCAC testen in dem du z.B. eine View erstellst und im RUNQRY dann diese statt der Originaldatei angibst (alternativ auch per OVRDBF).
Query meldet dann diverse Fehler und ggf. wird die Liste gar nicht mehr erstellt.

RCAC ist ein zusätzlicher Layer der direkt in den Tabellen aktiviert wird. Dafür müssen sämtliche Datenbankenzugriffe, also auch NativeI/O, Query400 und OPNQRYF über die SQL Query Engine ausgeführt werden, was seit Release 7.2 realisiert ist.

Query400 ist kein SQL und eine SQL View über RUNSQL auszuführen führt noch lange nicht dazu, dass RCAC nicht eingesetzt werden kann.

Da bekannt ist, dass Query und OPNQRYF anders als SQL optimiert werden und durch die Umstellung Performance Probleme (durch fehlende Indices) auftreten können, wurde eine Option in der QAQQINI bereit gestellt, um Queries und OPNQRYF u.ä. vorerst weiterhin mit der alten CQE auszuführen.

Nur in diesem Fall kann kein RCAC verwendet werden, bzw. bei aktivierter RCAC können die Queries nicht ausgeführt werden. Allerdings nur diejenigen Queries, die auf Tabellen mit aktivierter RCAC zugreifen.

Kleiner Tipp: Ab un zu schadet es nichts die Dokumentation zu lesen und etwas auszuprobieren.

Birgitta

[Fuerchau]

Mir ging es nicht um die generelle Funktionalität sondern um das Ausblenden von Spalten für Query oder gar eine Anwendung.

Wenn ich also mit RCAC irgendwas aus der DB ausblende ohne dass die Anwendung damit rechnet dass es sowas gibt, stirbt diese meist oder produziert Folgefehler.

Bei RCAC muss ich bereits im Anwendungsdesign berücksichtigen, dass Spalten-Inhalte ggf. nicht sichtbar sein können, spätestens beim Update/Insert gibts da ein Problem wenn dieser nicht durchgeführt wird weil gerade die Maske nicht passt.
Oder ich lese Tabelle A und schreibe was in Tabelle B, aber irgend ein Heini hat die Spalte in A maskiert, so dass ich in B dann blödsinn reinschreibe.
Und anschließend meckert da jemand über unverständliche Anwendungsfehler.

Ich habe schon bei normalen Anwendungen häufig genug die Nachweispflicht, dass das Problem vor dem Bildschirm sitzt.