DSJAUDJRNE for entry type CD

[Jack]

Hi,

I have a user with LMTCPB(*YES) who is able to perform an ENDJOB on any sessions on our AS/400 (V7R1). I set his user profile to be audited with the following command: CHGUSRAUD USRPRF(MYUSER) OBJAUD(*ALL) AUDLVL(*CMD).

I can now track his actions with the DSPAUDJRNE command. There is one weird thing I see when he performs the ENDJOB command. Below is what I see from the command DSPAUDJRNE ENTTYP(CD) USRPRF(MYUSER) FROMTIME(091514 111111) OUTPUT(*). To make it easier to read, each line is the equivalent of a column on the screen.

ENTRY TYPE: C
USER PROFILE: MYUSER
OBJECT NAME: ENDJOB
LIBRARY NAME: *SYSTEM
CL PGM: N
JOB NAME: MYJOB
JOB USER: MYUSER
JOB NUMBER: 008787
TIME STAMP: 2014-09-15-11.11.11.111111
COMMAND STRING: X: *SYSTEM/ENDJOB JOB(008787/RYLACROIX/LINE04)

As I understand it, the command is issued from the command line for the job number 008787. All other commands (not shown here) are under the job number 008787, excluding the fact that this could have been issued via RMTCMD or ODBC.

I do not understand as well the *SYSYEM library name.

And, most of all, I don't understand the "X:" in the command string. How did it get there?

Thank you for your help!

Jack

[Ken Sims]

Hi Jack -

On Mon, 15 Sep 2014 10:53:37 -0700 (PDT), Jack
<jacque...@gmail.com> wrote:

>As I understand it, the command is issued from the command line for the job number 008787. All other commands (not shown here) are under the job number 008787, excluding the fact that this could have been issued via RMTCMD or ODBC.
>
>I do not understand as well the *SYSYEM library name.
>
>And, most of all, I don't understand the "X:" in the command string. How did it get there?

I don't know much about these journal entries, but the presence of the
*SYSTEM implies to me that the command is probably being run by some
other program, not directly keyed.

The "X:" might confirm that. Chuck or someone can probably elaborate
on that.

Does the user have any access to view running jobs? WRKACTJOB,
WRKUSRJOB, or such?

LMTCPB(*YES) isn't going to block doing an option 4 to end a job from
within those commands.

--
Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

[jse...@yahoo.co.nz]

Hi Jack

The Limited capability flag on a profile is probably widely mis-understood.

First, it doesn't necessarily mean you can't run commands from the command line. Whether you can or can't is determined by the command itself. If you issue a DSPCMD <command name> you will see near the bottom of the first screen a flag as to whether a limited capability user can execute the command. This of course can be changed using the CHGCMD command.

Second, limited capability does not stop a user executing commands from a system menu or entering an option against something on a system screen like WRKACTJOB.

It's possible they may have access to something like WRKUSRJOB or WRKACTJOB and are placing a 4 beside the job. Alas the command audit journals do not keep track of menu options.

[Jack]

Here's the list of commands allowing users with limited capability:

QSYS/DSPJOB
QSYS/DSPJOBLOG
QSYS/DSPMSG
QSYS/SIGNOFF
QSYS/SNDMSG
QSYS/STRPCO
QSYS/WRKMSG

So, no access to something like WRKUSRJOB or WRKACTJOB.

You mentionned in your post "...does not stop a user executing commands from a system menu...". Exactly, how could a user be able to execute a command from the system menu? That could be how he does it...

Thanks!

[Ken Sims]

Hi Jack -

LMTCPB(*YES) does not apply to menu options. If the user is able to
get to a menu (system menu or user-created menu) which has WRKACTJOB
or WRKUSRJOB, then the user is going to be able to execute the command
(unless there is something else in the picture blocking the execution
of the command).

[Obelix]

Il 15/09/2014 19:53, Jack ha scritto:
> Hi,
>
> I have a user with LMTCPB(*YES) who is able to perform an ENDJOB on any sessions on our AS/400 (V7R1).

I had similar problem back. I solved them with

GRTOBJAUT OBJ(ENDJOB) OBJTYPE(*CMD) USER(MYUSER) AUT(*EXCLUDE)

Note that the default is *USE.

at that time, users was killing job using SysReq 2 in order to insert
wrong data into DB (BTW, it didn't work: user shou down the session by
pushing the windows close button. I had to switch to commit-controlled
program in order to avoid it...)

[Jack]

Thanks all for your replies. I learned a lot with your comments on the LMTCPB(*YES).

I finally found out how my user with LMTCPB(*YES) was able to cancel a job in the AS/400. We have an option in a in-house menu labeled "DSPJOB". In fact, the command invoked by the menu was WRKJOB. He was then able to go to option 12 (Work with locks), then option 8 (Work with object locks) and then use option 4 (End job). Et voilà!

We just replaced the call to the WRKJOB command by the DSPJOB command to fix the problem.

Once again, thank you very much!

[jse...@yahoo.co.nz]

On Wednesday, 17 September 2014 03:47:06 UTC+12, Jack wrote:
> You mentionned in your post "...does not stop a user executing commands from a system menu...". Exactly, how could a user be able to execute a command from the system menu? That could be how he does it...
>
>
> Thanks!

Sorry, I didn't explain myself properly. As Ken has pointed out, what I meant was they can select an option from the menu which will run the underlying command. LMTCPB is not checked for these. If they get access to a system menu which has something like WRKUSRJOB etc on it, then they can execute that command. From there they can place a 4 beside the job to end it. Again, LMTCPB is not checked.

[CRPence]

On 15-Sep-2014 12:53 -0500, Jack wrote:
>
> I have a user with LMTCPB(*YES) who is able to perform an ENDJOB on
> any sessions on our AS/400 (V7R1). I set his user profile to be
> audited with the following command: CHGUSRAUD USRPRF(MYUSER)
> OBJAUD(*ALL) AUDLVL(*CMD).
>
> I can now track his actions with the DSPAUDJRNE command. There is
> one weird thing I see when he performs the ENDJOB command. Below is
> what I see from the command DSPAUDJRNE ENTTYP(CD) USRPRF(MYUSER)
> FROMTIME(091514 111111) OUTPUT(*). To make it easier to read, each
> line is the equivalent of a column on the screen.
>
> ENTRY TYPE: C
> USER PROFILE: MYUSER
> OBJECT NAME: ENDJOB
> LIBRARY NAME: *SYSTEM
> CL PGM: N
> JOB NAME: MYJOB
> JOB USER: MYUSER
> JOB NUMBER: 008787
> TIME STAMP: 2014-09-15-11.11.11.111111
> COMMAND STRING: X: *SYSTEM/ENDJOB JOB(008787/RYLACROIX/LINE04)
>
> As I understand it, the command is issued from the command line for
> the job number 008787. All other commands (not shown here) are under
> the job number 008787, excluding the fact that this could have been
> issued via RMTCMD or ODBC.
>

> I do not understand as well the *SYSTEM library name.

>
> And, most of all, I don't understand the "X:" in the command string.
> How did it get there?

The "*SYSTEM" library qualification is an alias for the system
library which [in the /native/ environment] is the library QSYS. The
typical unqualified reference uses the library qualification of "*LIBL".
Yet another library qualification available is "*NLVLIBL" to search
the QSYS29## library\libraries before the library QSYS.

Features shipped by IBM, e.g. MENU options, are [mostly] explicitly
qualified with either *NLVLIBL or *SYSTEM to prevent being affected by
Trojan Horse variants of a command of the same name found in *LIBL; i.e.
whereby an equivalent command name might exist in a library that was
placed in a position prior to QSYS using either Change System Library
List (CHGSYSLIBL) or the System Library List (SYSLIBL) entry of the
subsystem. These specifications are intended to avoid negative effects
of even legitimate\intended Trojans that might have unintended effects
for work initiated by the system or a request by a user for an intended
effect advertised by the system; in this case, the End Job (ENDJOB) was
requested via a option from a list\menu.

As to the X:, I do not know for sure [because I do not recall ever
seeing any such prefix ever appear in the output], but I believe that
the "X:" indicates that the command utilized was actually a Proxy
Command (PRX); seems odd though, given the *SYSTEM qualification.? I
would expect the QSYS/ENDJOB to be a *CMD object without the Proxy
attribute.

I suppose the typical\standard /native/ environment command
invocations may appear with no designation [no prefix in the command
string data], but if they are similarly prefixed, the typical value
would be a C: instead, meaning "Command Run [without substitution by an
API invocation]". Refer to the following IBM i 7.2 [v7r2] documentation
which has a Change Bar for the T-CD (Command String) audit entry [as the
"Entry Type" entry-specific information]:
<http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlf10.htm>

--
Regards, Chuck