Re: Journal security.

[CRPence <CRPbottle@xxxxxxxxx>]

  Yep.  The default is FILE(*ALLFILE) which requires the user have 
authority to all objects [for which an entry is processed, I believe; if 
for instance the first sixty entries are all authorized, the request may 
fail only after several page down requests].  That is because the 
journal could be host to many various database files to which the user 
should not have any access, to see the data in those files.  The DSPJRN 
allows the user to effectively do just that, for any modified rows. 
When the user has authority to see the data in the named file [with the 
matching JID], then intuitively there is little\lesser reason they 
should be prevented from seeing that data also in the journal.  If they 
should not, the can be excluded from access to the receiver(s).

  I believe security rules require not listing [all of] the objects the 
user is not authorized to, because it is a /generic/ request versus an 
explicit attempt to access [information about] that object.  And even if 
it did log each, the recovery process could get ugly to resolve by a 
process of granting authority, repeating failed request, repeat grant, 
etc..  I think the CPF9802 naming the journal is a generic way to say 
"you may not do that"; too bad though, there is not also a diagnostic 
that clarifies the specific nuances about use of *ALL and *ALLFILE [and 
any other cases that might exist].

  The doc fails to clarify the authority requirement for the *ALLFILE 
single value.  And although the *ALL special value _does have_ an 
authority comment, it like many other places, seems to refer to /file/ 
rather than /object/; presumably in most cases it is the latter, even 
for *ALLFILE.

Regards, Chuck

rob@xxxxxxxxx wrote:
> Came across an interesting one today. Had a user who tried just:
> DSPJRN JRN(#MXJRN/BPCS_GDI) and got
> CPF9802 - Not authorized to object BPCS_GDI in #MXJRN.
> If, however, they changed the command to: 
> DSPJRN JRN(#MXJRN/BPCS_gdi) FILE((GDIDIVF/ECL)) No problem
> 12 entries converted from journal BPCS_GDI in #MXJRN.
>
> So, apparently there is some security under the covers that says:
> Hey, I don't know if you're dupa enough to journal the EmployeeRate
> table to the same journal as the OrderLine file, so, unless I know
> that you have access to the particular file that you are trying to
> see, you are SOL.
>
> Which, is probably as it should be.  Although that message had me 
> scrambling all over DSPOBJAUT of the journal itself before a coworker
> stumbled over the other item.