Switch user profile runtime

[voicucosmin90]

Hello,
It is possible to change the user profile during the runtime? I have to call another program for some CLLE's programs but this called program has to be called with a special user profile, I think to do this with SBMJOB CALL PGM(MY_PGM) USER(MY_USER) but if I want to use simply CALL can I switch in some way the user before the call, to be called with the special user? it is related to the user profile for SSH transfers, who is able to connect through public key to another user.
Thanks

[Vectorspace]

http://www.mysamplecode.com/2012/06/as400-switch-user-profile.html

https://www.mcpressonline.com/security/general/techtip-change-the-user-profile-for-the-currently-running-job

[tdavis]

I wrote a command called SWAP which allows me to swap to another user profile when necessary. I used it most recently for SFTP file transfers to a Unix server using SSH. Since I didn't want to exchange SSH keys for an unknown number of users, I am instead doing a swap to a common user profile and then executing the SSH commands. The command uses an IBM API called QWTSETP. I didn't write the program, so I am not taking credit. Found it somewhere but cant remember now.... here it is....

H DFTACTGRP(*NO) BNDDIR('QC2LE')

D RtvProfile PR 10I 0
D userid 10A value
D password 10A value

D SetUProf PR 10I 0
D handle 12A value

D Handle S 12A
D RC S 10I 0
D LC C 'abcdefghijklmnopqrstuvwxyz'
D UC C 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

D GetProfile PR ExtPgm('QSYGETPH')
D UserID 10A const
D Password 10A const
D Handle 12A
D ErrorCode 32766A options(*varsize: *nopass)

D SetProfile PR ExtPgm('QWTSETP')
D Handle 12A const
D ErrorCode 32766A options(*varsize: *nopass)

D ErrDs DS
D BytesPrv 1 4I 0 INZ(256)
D BytesAvl 5 8I 0 INZ(0)
D ErrMsgID 9 15
D Reserved 16 16
D ErrMsgDta 17 256

DToUser S 10a
DToPassWord S 10a

c *Entry Plist
c Parm ToUser
c Parm ToPassWord

* Retrieve the User Profile Handle
c eval RC = RtvProfile(ToUser:ToPassWord)
c If RC <> 0

* Now Set the Job Profile to a NEW User Profile
c eval RC = SetUProf(handle)
c Endif
c Eval *Inlr = *On

*================================================= =============*
* Get User Profile Handle SubProcedure *
*================================================= =============*
P RtvProfile B
D RtvProfile PI 10I 0
D userid 10A Value
D password 10A Value


c Eval UserID = %Xlate(LC:UC:UserID)
c Eval Password = %Xlate(LC:UC:Password)

c callp GetProfile(UserID: Password: handle: ErrDS)
c if BytesAvl > 0
c return 0
C Else
c return 1
c endif

P E

*================================================= =============*
* Set User Profile To New User Profile SubProcedure *
*================================================= =============*
P SetUProf B
D SetUProf PI 10I 0
D HandleIn 12A Value

c callp SetProfile(handleIn: ErrDs)
c if BytesAvl > 0
c return 0
C Else
c return 1
c endif

P E

[john.sev99]

It's intriguing that no-one ever seems to release the profile handle afterwards. Probably not an issue, but if used in a server job that is continually swapping profiles, you may reach the maximum number of profile handles.

However, you need to be aware of issues around the use of these APIs. When you use the swap user APIs, your job will forever run under that user profile (as if you had logged on using the swapped-to profile) until it is swapped back again. If your program should error and crash, the user will unknowingly be running under the swapped to profile until they log off. As such, error checking is a must throughout the programs that use it. Also, if a person breaks out of the program before the ID is swapped back (SYSREQ-2), again they will be running under that user ID. Same goes if they access options from the SYSREQ menu or a command attention program etc etc.
As such, I would not recommend using these APIs for anything but batch jobs.

[Barbara Morris]

...

However, you need to be aware of issues around the use of these APIs. When you use the swap user APIs, your job will forever run under that user profile (as if you had logged on using the swapped-to profile) until it is swapped back again. If your program should error and crash, the user will unknowingly be running under the swapped to profile until they log off. As such, error checking is a must throughout the programs that use it. Also, if a person breaks out of the program before the ID is swapped back (SYSREQ-2), again they will be running under that user ID. Same goes if they access options from the SYSREQ menu or a command attention program etc etc.
As such, I would not recommend using these APIs for anything but batch jobs.

RPG has a relatively new ON-EXIT feature (recent enhancement PTFs for 7.2 and 7.3). You can add an ON-EXIT section to a procedure containing code that will run no matter how the procedure ends (reach the end of the procedure, hit a RETURN opcode, crash, SYSREQ, F3 out of debug session, end subsystem, etc).

So, if the swap, do-something, and swap-back are all in the same procedure, then the swap-back can be put into the ON-EXIT, and the profile would always be swapped back.

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzasd/zzonexit.htm

dcl-proc p1;
   dcl-s need_swap_back ind inz(*off);

   --- call the API to do the swap
   if successful;
      need_swap_back = *on;
   endif;

   --- do some stuff under the new profile

on-exit;
   if need_swap_back;
      --- call the API to swap back
   endif;
end-proc;

[john.sev99]

That's quite a handy feature addition to the language.
However, that's only if the RPG program ends for some reason. If the person gets access to functions by some other means such as an attention key program or sys-req menu (the program is still running when these are pressed) anything they do is under the swapped-to profile so I still believe the safest approach is to only allow them to be used in batch jobs.

As an aside, looking at the OP again, I notice it mentions requiring it for SSH. Why? You can use the "-i" switch on the SSH command to use an identity_file which may be all that's required. I guess that's another can of worms though as they'd need access to the keys to do that...

[tomliotta]

Fully agree with always switching back after finishing the work under the switched profile. I always wrap the switched work between the switch-to and switch-back functions and monitor errors as well as work at controlling Attn_key, etc. It's a bit of a battle to keep up with possible holes, but it helps to keep code in procs that can be updated as new requirements are discovered.