I've had an initial discussion with a c# developer for this app, and he is
unaware of any pooling, but they are using connection modules developed by
previous (and now long gone) coders. This one application is user sensitive
on the Power i side, where as everything else they develop (that I can think
of) is secured by Win profile tables (by customer and levels within
customer). Tomorrow I can pursue this with the other developers.
Thanks to all for the details in sorting this out.
Jim Franz
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Monday, September 14, 2015 6:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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"].
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
