× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Steve McKay wrote on 05/05/2008 03:44:54 PM:

I've played with this most of the day and have come to the conclusion
that
you're correct - Wayne's trick of swapping to the same user profile
without
specifying *CURRENT has probably been PTFed and no longer works. Here is

the code in question:

CALL PGM(QSYGETPH) PARM(&USER '*NOPWD' &LOGCMD)
CHGUSRAUD USRPRF(&USER) AUDLVL(&AUDLVL)
CALL PGM(QWTSETP) PARM(&LOGCMD)
CALL PGM(QSYRLSPH) PARM(&LOGCMD)

When I execute this part of the program followed by a call to QCMD, the
&USER user profile (my user profile) has *CMD as an "auditing action" but

subsequent commands entered do not show up in QAUDJRN. If I immediately
sign off and back on, all commands entered after sign on are logged to
QAUDJRN, so it appears that the warning in CHGUSRAUD about changes not
taking effect until another job is started for the user is being
enforced.

Do I have other options without setting everyone's profile auditing
action
to *CMD or executing the *SPENDMONEY (RIP Al B.) command?

That code is very close but not correct. Before I share code that does work
on V6R1 (and probably other releases) I will first say that I do not like
the idea of giving any user access to a command line where they have
*ALLOBJ authority. Doing this is almost as bad as giving them *ALLOBJ all
of the time. They can do virtually anything on the system. So the only
group of people I would give authority to run the following program are
those people that I would be willing to give two user profiles, one with
*ALLOBJ authority and one without. With this program you only have to
create the user profile without *ALLOBJ authority. So most of the time they
are running without *ALLOBJ authority.

The key to the program is that the profile must be changed before the
profile handle for that user profile is created. (Someone must have moved
the CHGUSRAUD command in Wayne's LOGCMD program.) Instead of just adding
*CMD auditing I decided it was less work and better for security to just
turn on all auditing for the user profile. (That way I did not have to
figure out what auditing was already turned on for the user.) If your
system is not at V6R1, some of the AUDLVL value on the CHGUSRAUD command
will not be supported. If that is the case I suggest adding a MONMSG after
the CHGUSRAUD and trying the command again with the values that will work
on your system. That way when you do move to V6R1 the program will continue
to turn on all auditing.

One other thing I did is call QUSCMDLN instead of QCMD. I did this to help
remind people that are used to using QCMD, that they are in a different
environment. Hopefully they will be encouraged to get off the pop-up
command line and back to their normal environment.

PGM
DCL VAR(&CURRENT) TYPE(*CHAR) LEN(12)
DCL VAR(&SAMEUSR) TYPE(*CHAR) LEN(12)
DCL VAR(&USER) TYPE(*CHAR) LEN(10)
DCL VAR(&OBJAUD) TYPE(*CHAR) LEN(10)
DCL VAR(&AUDLVL) TYPE(*CHAR) LEN(640)

QSYS/RTVUSRPRF RTNUSRPRF(&USER) OBJAUD(&OBJAUD) AUDLVL(&AUDLVL)
QSYS/CHGUSRAUD USRPRF(&USER) OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD +
*CREATE *DELETE *JOBDTA *NETCMN *OBJMGT *OFCSRV +
*OPTICAL *PGMADP *PGMFAIL *PRTDTA *SAVRST +
*SECURITY *SERVICE *SPLFDTA *SYSMGT)
CALL PGM(QSYS/QSYGETPH) PARM('*CURRENT' '*NOPWD' &CURRENT)
CALL PGM(QSYS/QSYGETPH) PARM(&USER '*NOPWD' &SAMEUSR)
CALL PGM(QSYS/QWTSETP) PARM(&SAMEUSR)
CALL PGM(QSYS/QSYRLSPH) PARM(&SAMEUSR)

CALL PGM(QSYS/QUSCMDLN)

QSYS/CHGUSRAUD USRPRF(&USER) AUDLVL(&AUDLVL)
CALL PGM(QSYS/QWTSETP) PARM(&CURRENT)
CALL PGM(QSYS/QSYRLSPH) PARM(&CURRENT)

ENDPGM

You pointed out one problem with programs like this. If the user of the
program signs-off at the command line or their job is ended for any reason
then they will continue to have all auditing turned on. You may be able to
solve that problem by using a scope message to call another program to
restore auditing for the user profile. Or, this may be the case where it is
time to spend money for a product that solves this and other(?) problems.

Something else to think about. Instead of using this program perhaps you
should create one that uses the adopted authority to swap to a user profile
that has the necessary special authorities and auditing already turned on.
Then call QUSCMDLN and then swap back. That way you do not have to clean up
the users profile if the job ends. The security audit records will contain
both user profiles, the initial one in the job name fields and the current
user profile field.

Ed Fishel,
edfishel@xxxxxxxxxx


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.