Berechtigung bei STRQL nicht berücksichtigt, jedoch bei JDBC?!

[volker.goers]

Hallo Zusammen,

ich stehe gerade etwas auf dem Schlauch.
Wenn ich über JDBC (z.B. DBeaver) mit einem Benutzer versuche ein SELECT auf eine für den Benutzer nicht berechtigte Tabelle zuzugreifen, wird der Zugriff mit der Fehlermeldung:
SQL-Fehler [42501]: [SQL0551] Keine Berechtigung für Objekt ANWDTAMTM in QSYS, Art *LIB
abgewiesen.
Soweit so gut, das korrekt und so gewollt.

Wende ich den SELECT mit dem gleichen Benutzer auf die gleiche Tabelle im STRSQL-Command (GreenScreen) an, so wird der Zugriff gewährt und die Daten werden angezeigt.
Wie kann das sein?

Der Benutzer ist Mitglied in einer Berechtigungsliste XXX und einer Benutzergruppe XXX (mit Gruppenberechtigung *NONE, Art *PRIVATE).
Die Bibliothek (Hier AnWDTAMTM) der nicht berechtigten Tabelle ist durch die Berechtigungsliste YYY geschützt (mit *PUBLIC=*EXCLUDE und Benutzergruppe YYY=*ALL).
Die Tabelle selber ist mit der Berechtigungsliste YYY geschützt (mit *PUBLIC=*EXCLUDE und Benutzergruppe YYY=*ALL).

Der aufrufende Benutzer hat die Benutzerklasse *USER und keine Sonderberechtigungen.
Er ist definitiv nicht Mitglied der Benutzergruppe YYY und auch kein Mitglied der Berechtigungsliste YYY.
In der Berechtigungsliste YYY steht *PUBLIC=*EXCLUDE.

Wie kann STRSQL den Zugriff gewähren, während DBeaver oder 'SQL-Scripts ausführen' vom ACS den Zugriff korrekterweise verweigern?
Dies betrifft nicht nur diese Tabelle allein.
Es scheint so, das STRSQL alle Berechtigungen in den Wind schlägt?!

Hat jemand eine Idee?

Die Maschine hat V7R4M0 mit
CUMULATIVE PTF PACKAGE (SF99740) Level 25107 und
DB2 FOR IBM I (SF99704) Level 31.

Vielen Dank schon mal vorab.

Volker

[volker.goers]

Hallo Zusammen,

habe die Ursache gefunden, den entscheidenden Hinweis gab mir unsere KI (wozu so nen Ding doch gut sein kann :cool.

Antwort hier: Adopted Authorities.

Auf dieser Maschine war ein Startprogramm, dass bei den Benutzerprofilen hinterlegt war, mit *OWNER gewandelt worden (auf anderen Maschinen korrekterweise mit *USER).
Alle Benutzer bekamen auf dieser Maschine somit viel zu viele Rechte und die haben sich auch beim STRSQL ausgewirkt und somit wurde das Berechtigungskonzept untergraben..
Bei JDBC werden, da kein Startprogramm, keine Rechte vererbt und somit hat das Berechtigungskonzept gegriffen.

Grüße
Volker

[Fuerchau]

Vor sowas, adopted Authority, hatte ich früher schon gewarnt, dass dies zu vielen Problemen führen kann.
Der Witz ist auch, sollte in einer Gruppe ein Benutzer *ALLOBJ ausweisen, so kann ich mir alle Zugriffe nehmen, wenn ich eine Kommandozeile habe.
Durch dieselbe Gruppe kann ich einen SBMJOB mit der Berichtigung des anderen Users ausführen lassen.
Somit habe ich in diesem Job *ALLOBJ.
Erst mal noch kein Problem.
Allerdings kann ich dadurch einen 2. SBMJOB mit User QSECOFR durchführen.
Da dies allerdings tatsächlich vom Berechtigungssystem geprüft und abgewiesen wird, gibts eine andere Lösung.
Mittels ADDJOBSCDE kann ich mit *ALLOBJ einen Planungseintrag für jeden beliebigen User, also auch QSECOFER, erstellen. Das ist mit der Berechtigung dann erlaubt.
Nun kann ich als Startzeit *IMMED (o.ä.) und als Frequenz *ONCE angeben, m.a.W. der Job rennt durch und ist wieder weg.
Was hinder mich also daran mittels:

sbmjob ..... cmd(addjobscde ..... cmd(chgusrprf me *ALLOBJ, *SECADM) *IMMED *ONNCE USRPRF(AllObjUser))

Der Witz daran?
Das kann ich auch per SQL, da ein "CALL QCMDEXC ...." auch mit SQL erlaubt ist, obiges Kommndo durchführen.

[Pikachu]

Geht das alles auch noch bei Sicherheitsstufe QSECURITY 40 oder höher?

[Fuerchau]

Das hat damit nichts zu tun. In dieser Stufe wird die Objektsicherheit erhöht.
Am Berechtigungskonzept ins besonders von *ALLOBJ ändert das nichts.
Es sei denn, das weiß ich nicht, dass *ALLOBJ dann nicht mehr erlaubt wird.

Übrigens: Wer das Produkt Infor XPPS im Einsatz hat, sollte wissen dass ein
CALL XXUSER 'NAME'
ohne Kennwort einen Contextswitch erlaubt. QSECOFR ist da natürlich ebenso möglich.
Da bedarf es noch nicht mal eines SBMJOB's.
Bedient werden damit die API's QSYGETPH / QWTSETP.
https://www.ibm.com/docs/en/i/7.6.0?.../QSYGETPH.html
https://www.ibm.com/docs/en/i/7.6.0?...s/QWTSETP.html

Wenn man also neben der Kommandozeile also auch noch Programme schreiben kann, der kann sich damit durchaus als andere Person ausgeben.

Ich hatte mal einen Kunden, bei dem der Logistikleiter sein Kennwort vergessen hatte und sich selber disabled hatte. Der IT-Leiter befand sich allerdings in Urlaub und sonst war niemand mit Berechtigung vorhanden. Somit konnte keine Lieferung mehr erfolgen.
Der Notruf erreicht mich und ich kam remote mit einem anderen noch funktionierenden Profil auf die Maschine. Durch die normale Analyse, welches Profil nun da *ALLOBJ hatte und das ich auf grund der Berechtigung verwenden durfte, konnte ich mir SECADM geben und das Kennwort zurückstzen.
Ohne ein *ALLOBJ hätte man wohl den IT-Leiter schnellstens aus dem Urlaub holen müssen.

[BenderD]

... in der SQL Denke, kommt die Berechtigung auf die Datenbank über den connect. Das hat man bei native AS/400 Anwendungen leider abgeklemmt, da wird automatisch unter dem aktuellen Profil connected. Zu dem Scheunentoren bei adopted Authority mag ich mich öffentlich nicht äußern - das ist so schon schlimm genug.

D*B

[Fuerchau]

Man benötigt adopted Authority halt nicht, wenn man auf ein Profil mit *ALLOBJ Zugriff bekommt.
Da nun für fast jedes API auch eine SQL-View existiert, gibts wahrscheinlich auch eine View für USRPRF's, so dass es leicht ist herauszufinden, wer denn *ALLOBJ hat.
https://www.rpgpgm.com/2015/11/getti...-profiles.html

Aus SQL-Sicht gibts ja auch 3 Profil-Variablen:
https://www.ibm.com/support/pages/cu...considerations