Re: Odd security issue with adopted authority

On 14-Sep-2015 15:17 -0600, Jim Franz wrote:

<<SNIP>>
Can I trust the user profile in a joblog of QZRCSRVS : did a F1 help
on the CPF9802 and F9 for Display message details - in this example
we know COKEK was not the user who made the request (she is the 1st
user when this particular QZRCSRVS job started) and am thinking the
Win side is connecting to an existing connection for another user.

As I recall, the message identifier xxxyyyy that logs the current user [with text stating something like "job currently is servicing user &1"] is /correct/ for the job; i.e. the most recent xxxyyyy, though I seem to recall there is ever only one logged, else the joblog is wiped clean as part of job-reuse or instead per the job having ended.

If the job is reused, then that message xxxyyyy names the new user attached to the new\reused job. If the job is not reused, then that message xxxyyyy would have logged the initial user that is currently or was previously accessing the system, and any later messages logged will refer to work initiated by that same named user; the job is continuing to await more commands from the same user, or to be recycled\reused according to timeouts and pre-start job configuration\settings. I expect that a possible exception to what I described, would be if the /command/ performed by the server job included a switch-user request that was not reverted.?

Message ID . . . . : CPF9802 Severity . . . . . : 40
Message type . . . : Escape
Date sent . . . . : 09/14/15 Time sent . . . . : 13:53

Message . . . . : Not authorized to object GR_NONXYZ in QSYS.
Cause . . . : You do not have the correct authority for object
GR_NONXYZ in library QSYS type *USRPRF.
Recovery . . . : Contact your security officer or the object owner
to obtain the correct authority and try your request again.

Message ID . . . . : CPF9802 Severity
Date sent . . . . : 09/14/15 Time sent
Message type . . . : Escape
From . . . . . . . : COKEK CCSID .

From program . . . . . . . : QSYUP
From library . . . . . . : QSYS
Instruction . . . . . . : 3F1D

To program . . . . . . . . : K002C
To library . . . . . . . : KMD
To module . . . . . . . : K002C
To procedure . . . . . . : K002C
To statement . . . . . . : 2080

Time sent . . . . . . . . : 13:53:17.924614

The User named in the "From" may be the "current user" at the time the F1=Help [or Display Job Log (DSPJOBLOG) command] is issued rather than the current user that was active when the message was issued; i.e. quite possibly the data comes from a pointer, from which the object name gets materialized during the processing of the Display\Receive Message request, rather than being retrieved from a stored-value that was materialized when the message was originally issued.

However that is easily rendered moot, a non-issue, by reviewing instead, the T-AF entry in the Audit Journal; i.e. look at auditing results instead of looking at message(s) in the joblog.

I'm not entirely clear how the OS decides which connection is to
which QZRCSRVS job or if that is more of a client socket decision.
The C# developers gone for today to ask.

The QZRCSRVS server jobs are for the TCP Remote Command feature, and the current-user should reflect the user profile that was utilized for the Host Server authentication to the system [via, IIRC, the Signon Server (*SIGNON server)].

Any suggestions on how to determine which QZRCSRVS job handles a
particular request would help. I've changed the jobd to log 4 00
*seclvl and logclpgm = *yes to see more detail .

IIRC there is an exit-point into which an exit-program can be assigned. But as noted earlier, the simplest for the given scenario likely is just [to establish auditing to include Authority Failure (*AUTFAIL) events, and then] to review the T-AF in the log\journal-receiver.

Possibly easier still, is to use debug; add a breakpoint at the failing statement\instruction, and then while the job is at the breakpoint, review what is the value of "Current User Profile" for the job [i.e. WRKJOB OPTION(*STSA)]. For example ADDBKP '/3F1D' PGM(QSYUP) or establish a breakpoint at statement 2080 of the procedure K002C in program K002C in library KMD; for the latter, add a SEP breakpoint to avoid having to track-down the specific server-job to service [which is probably the impetus for the "determine which QZRCSRVS job"].