Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to get authority for CHGUSRPRF in a CLP

606 views
Skip to first unread message

Doug

unread,
May 26, 2004, 3:40:12 PM5/26/04
to
We have several groups on our AS/400. We wish to delegate the USRPRF
administration to each separate group. I inherited a set of programs
to do this. We first use EDTOBJAUT to add the XXSECADM user to each
USRPRF that XXSECADM is to administer. That would be the users in the
XX group. The XXSECADM user is given *SECADM special authority. The
programs are structured so that the first is a CL that creates a file
from DSPUSRPRF *ALL which only sees the USRPRFs to which XXSECADM has
been given authority to. This CL calls an RPG program that produces
the browsable list of USRPRFS. On this screen, you can select to view
or change a USRPRF. This RPG program calls another CL program to do
the actual CHGUSRPRF.
Now each USRPRF in group XX has a group profile of XXGRP. We
discovered that our XXSECADM user could not reset passwords because
XXSECADM did not have access to the XXGRP. So we used EDTOBJAUT to
cover the XXGRPs. That seemed to work. Until they wanted to change a
printer for a USRPRF. Now they didn't have access to the printer.
Rather than mess with EDTOBJAUT on each and every thing, I thought
I could use adopt authority to handle it. On the CL program that does
the CHGUSRPRF, I set USRPRF to *OWNER and made the owner QSECOFR.
Much to my surprise, this did not work.
I have another CL program that is called directly which is set up
with *OWNER and QSECOFR that works as expected. It is using the old
programming model (you know, before ILE). This new set of programs is
all ILE.
Any help with why this doesn't work?

Denny Davis

unread,
May 26, 2004, 4:03:14 PM5/26/04
to
It should work.

Does one of the programs in the stack specify Use Adopted Authority
*NO?

Denny

Tim M

unread,
May 27, 2004, 12:59:45 AM5/27/04
to

"Doug" <doug....@spcorp.com> wrote in message
news:d7a6c64b.04052...@posting.google.com...

The user who is adding another user profile to a group profile must have
object management rights to the group profile and those rights may not
be inherited by adopting authority

Doug

unread,
May 27, 2004, 10:36:39 AM5/27/04
to
"Tim M" <scot...@cox.spammerssuck.net> wrote in message news:<7zetc.47093$bS1.11523@okepread02>...

That sounds plausible but I have another CLP that runs stand-alone and
is able to make any changes without having any rights to the group
profile other than the adopted authority of QSECOFR.

Doug

unread,
May 27, 2004, 10:39:05 AM5/27/04
to
The top two have *YES. I have tried the third (the CLP which does the
CHGUSRPRF) with *YES and *NO. I figured it didn't much matter since
the third program was using *OWNER.

Denny Davis <sp...@nowhere.com> wrote in message news:<ltt9b09b0uj6fkqvu...@4ax.com>...

Doug

unread,
May 27, 2004, 1:04:58 PM5/27/04
to
"Tim M" <scot...@cox.spammerssuck.net> wrote in message news:<7zetc.47093$bS1.11523@okepread02>...

It appears that you are indeed correct. I discovered that the CLP
that was working did not allow a change of the GRPPRF. When I added
that parameter, it failed the same as the CLP that is called by the
other programs. So even though no change is being made to the GRPPRF,
the presence of the parameter causes additional checking. This also
occurs on other parameters (like PRTDEV)which is the root of the
problem. How can you delegate user profile management if you have to
give rights to every object that might be changed?

Tim M

unread,
May 27, 2004, 6:50:09 PM5/27/04
to

The extended help for CHGUSRPRF clearly explains this restriction,
furthermore it only applies to the group and supplemental group
parameters.

If you are having troubles with other parms, then it is due to other
reasons.

The simplest solution to the problem is to grant *OBJMGT authority on
the group profiles to those users that are allowed to maintenance user
profiles.

The other work-around is to have the program swap user profiles to a
user id with sufficient authority by using the QSYGETPH, QWTSETP APIs

The following CL program and command definition demonstrates a
generalized CL program for executing commands under another user
profile:

WRKASUSER ADMIN CMD('CHGUSRPRF JOHNUSER GRPPRF(GROUPA)')

/********************************************************************/
/* This is the command processor program for the WRKASUSER command. */
/* */
/* Be sure to compile with USRPRF(*OWNER) */
/********************************************************************/
PGM (&NEWUSER &CMDSTR)
DCL &NEWUSER *CHAR 10
DCL &CMDSTR *CHAR 512
DCL &OLDHANDLE *CHAR 12
DCL &NEWHANDLE *CHAR 12
DCL &MSGKEY *CHAR 4

Dcl &ErrMsgId *Char 7
Dcl &ErrMsgFile *Char 10
Dcl &ErrMsgFlib *Char 10
Dcl &ErrMsgDta *Char 512

Dcl &ErrFlag *Lgl Value('0')

/*-----------------------------------------------------------------*/
/* By making the program a request processor, SYS RQS 2 (CNLRQS) */
/* can be trapped and the profile swapped back */
/*-----------------------------------------------------------------*/
SNDPGMMSG MSG('make rpp') TOPGMQ(*SAME) MSGTYPE(*RQS) +
KEYVAR(&MSGKEY)
RCVMSG MSGTYPE(*RQS) MSGKEY(&MSGKEY) RMV(*NO)

/*-----------------------------------------------------------------*/
/* Save the current job's profile handle, then get the get the */
/* the handle of the new user profile */
/*-----------------------------------------------------------------*/
CALL QSYGETPH (*CURRENT *NOPWD &OLDHANDLE)
CALL QSYGETPH (&NEWUSER *NOPWD &NEWHANDLE)
CALL QWTSETP (&NEWHANDLE)

/*-----------------------------------------------------------------*/
/* Execute the command in the command string */
/*-----------------------------------------------------------------*/
CALL QCMDEXC (&CMDSTR 512)
MONMSG MSGID(CPF0000) +
EXEC(DO)
/*-------------------------------------------------------------*/
/* Get the escape message that caused QCMDEXC to fail */
/*-------------------------------------------------------------*/
CHGVAR &ErrFlag '1'
RCVMSG MSGTYPE(*EXCP) MSGDTA(&ErrMsgDta) MsgId(&ErrMsgId) +
MSGF(&ErrMsgFile) SNDMSGFLIB(&ErrMsgFLib)
ENDDO

/*-----------------------------------------------------------------*/
/* Removing the request message changes the program back to a */
/* normal program
/*-----------------------------------------------------------------*/
RMVMSG MSGKEY(&MSGKEY)

CALL QWTSETP (&OLDHANDLE)
CALL QSYRLSPH (&NEWHANDLE)
CALL QSYRLSPH (&OLDHANDLE)

IF &ErrFlag +
SNDPGMMSG MSGID(&ErrMsgID) MSGF(&ErrMsgFLib/&ErrMsgFile) +
MSGDTA(&ErrMsgDta) MSGTYPE(*ESCAPE)
ENDPGM

/* Command definition */
CMD PROMPT('Work as User')
PARM KWD(USER) TYPE(*SNAME) LEN(10) MIN(1) +
PROMPT('User Name')
PARM KWD(CMDSTRING) TYPE(*CHAR) LEN(512) MIN(1) +
PROMPT('Command')

lopej...@gmail.com

unread,
May 31, 2016, 9:29:34 PM5/31/16
to
Hello Doug,

I am working on a very similar program to delegate user administration to users and I am new to CL Programming.

I would appreciate if you can share few insight in Coding for CL for the CHGUSRPRF command. I tried doing it but it does not prompt for the changing of the profile and CL just executes the command.

Please can you guide me?

Justin Lopes

jse...@yahoo.co.nz

unread,
Jun 1, 2016, 5:28:01 PM6/1/16
to
On Wednesday, 1 June 2016 13:29:34 UTC+12, lopej...@gmail.com wrote:
> Hello Doug,
>
> I am working on a very similar program to delegate user administration to users and I am new to CL Programming.
>
> I would appreciate if you can share few insight in Coding for CL for the CHGUSRPRF command. I tried doing it but it does not prompt for the changing of the profile and CL just executes the command.
>
> Please can you guide me?
>
> Justin Lopes

I would strongly advise against using the swap profile technique. It can lead to security exposures and the person permanently running under the swapped-to profile until they log off.
It would be better to use a program that adopted authority and you gave the necessary authority to the group profiles.

CRPence

unread,
Jun 20, 2016, 9:39:24 AM6/20/16
to
On 31-May-2016 20:29 -0500, lopej...@gmail.com wrote:
> <<SNIP>> Coding for CL for the CHGUSRPRF command. I tried doing it
> but it does not prompt for the changing of the profile and CL just
> executes the command.
>
> Please can you guide me?

To effect implicit prompting of a command within a CLP, code the
command [as CLP statement] with a question mark preceding the command; e.g.:

?CHGUSRPRF (&usrName)

Note: when the prompted command is ended by F3|F12 [rather than the
user pressing Enter], the statement will fail with CPF6801, so be sure
to monitor\handle appropriately that escape message, using the MONMSG
statement.

Note: there are other /prompt control characters/ [aka Selective
prompt characters] for use preceding individual keywords; I would have
provided a doc link to recent documentation, but after a couple
unfruitful searches and links that served up no results [empty pages], I
gave up :-( I am not sure if the "Prompting for user input at run time"
topic at
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rbam6/clpro.htm] might
be the correct direction, similar to the really old docs here:
[http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AUO03/6.5.2?SHELF=QB3AYC08&DT=19991014091328]

p.s. given the current topic seems not to be directly related to the
"Subject:", rather than post a reply to a twelve year old posting,
probably better to just open\post a new topic -- newsgroups do not
maintain the historical messages, so finding\reading the other messages
requires a redirect to an archive.

--
Regards, Chuck
0 new messages