Zugriff auf PF/LF mit *PUBLIC *EXCLUDE funktioniert nicht

[Kozuchowski]

Guten Tag,

die Steuerung von Berechtigungen für LIB's via AUTL und *Public=*Exclude funktioniert tadellos. Nun bin ich gezwungen in einer "zugänglichen" LIB die berechtigung für eine physische (ggf. aiuch logische) Datei so zu steuern, das nur bestimmte User (via AUTL) auf die Datei (Inhalt) zugreifen können. Ein erster Versuch mit *Public=*Exclude und Verwendung einer AUTL brachte überhaupt keinen Erfolg. Ein (eigentlich) nicht berechtigter User konnte via "Query" ohne Probleme auf die Datei (PF) und deren Inhalt zugreifen. Warum läuft die Berechtigungssteuerung auf PF anders als auf LIB's ? Das "Security-Handbuch" ist nicht wirklich eine Hilfe.

[Fuerchau]

Eigentlich müsste es funktionieren.
Wenn ein User oder das Gruppenprofil des Users jedoch *ALLOBJ-Berechtigung hat, darf er trotzdem alles.

Wenn die PF auf *PUBLIC *EXCLUDE steht, jedoch die LF auf *USE kann trotzdem von der LF gelesen werden.

[Kozuchowski]

Hallo Fuerchau,

vielen Dank für das schnelle Feedback.

Ich hab' nochmal genau nachgesehen....keine zusätzlichen Berechtigungen im Userprofil oder im Gruppenprofil. Wir haben "SECURITY=30" und lt. "Security Reference" gibt's somit keine "*ALLOBJ"-Berechtigung bei Benutzerklasse "*USER" ....(oder schmeiß' ich hier 'was durcheinander ??)

gruß

[Fuerchau]

Wie ist denn die Public-Berechtigung in der AUTL definiert ?

*ALLOBJ kann man einem profil explizit erteilen.

[BenderD]

... durchaus, durchaus - Benutzer mit Benutzerklasse *USER werden unter seclevel 30 ohne *allobj angelegt, wenn sie allerdings vorher angelegt wurden, oder ein Dösbattel (der zuweilen behauptet seine grandiose Software brauche das) dem Benutzer oder gar einem Gruppenprofil *ALLOBJ vergibt, dann hat er das, unabhängig von Seclevel und Benutzerklasse.

D*B

Hallo Fuerchau,

vielen Dank für das schnelle Feedback.

Ich hab' nochmal genau nachgesehen....keine zusätzlichen Berechtigungen im Userprofil oder im Gruppenprofil. Wir haben "SECURITY=30" und lt. "Security Reference" gibt's somit keine "*ALLOBJ"-Berechtigung bei Benutzerklasse "*USER" ....(oder schmeiß' ich hier 'was durcheinander ??)

gruß

[Dschainers]

Was bedeutet "Query"?
STRQRY oder MSQuery?
von wo aus wird Query aufgerufen?

Grüße
Dschainers

[Kozuchowski]

Hallo,

nochmals Alles geprüft.......
Im USRPRF ist definiert "SPCAUT=*NONE" und "GRPAUT=*NONE / GRPAUTTYP = *PRIVATE" als auch "SUPGRPPRF=*NONE".
Im GRPPRF finden sich die gleichen Einträge.
Warum funktioniert dann die OBJ-Berechtigung nicht ?
Woher (zum Geier) kommt denn dann die *ALLOBJ-Berechtigung ??.
Aus den "Profilen" definitiv nicht !!
Gibt es ein "Systembefehl", mit dem ich mir die Berechtigungen des Users ansehen kann ??

So langsam wird's "frustig" ........ und Danke für die Unterstützung.

[Kozuchowski]

Hallo Dschainers,

der Aufruf "Query für den Anwender" erfolgt über ein CL mit Aufruf "WRKQRY".
Liegt hier das Problem ??

[Dschainers]

Wenn das CL mit USRPRF(*owner) umgewandelt ist, dann ja

[Dschainers]

Dann erhält nämlich der USER alle Rechte des Programmeigners

[Kozuchowski]

Hallo,

DAS war es !!

Habe das "kleine CL" nochmals (richtig) gewandelt und "USEADPAUT(*NO)" hinterhergeschoben ......... schon klappt es wieder mit dem Nachbarn.

Vielen Dank für die Unterstützung !!

gruß

[holgerscherer]

Hallo,

DAS war es !!

Jaja, die kleinen versteckten Bomben, die irgendjemand mal hinterlassen hat - wäre mal ein interessantes Thema für einen Workshop.

Mein Liebling war in einer selbstgestrickten Anwendung die Option 99 (die man fast überall eingeben konnte), und es kamm ein QCMD als *SECOFR

-h