Calling password API in CL program

[Guest.Visitor]

A client on our AS/400 requires a production ID set up with extra security to allow the programmers to do some things they cannot do with their own ID's. What I want to do is when one of the programmers logs on with the production ID call in a program that will have the user enter his or her own ID and password and update a log before allowing them into the production ID. Has anyone ever called in the password API in a program that allows you to compare a users password? If so how is it done? Thanks in advance.

[Guest.Visitor]

Wade, Take a look at the Get Profile Handle (QSYGETPH) and Set Profile (QWTSETP) APIs that are documented at http://publib.boulder.ibm.com/pubs/h...s/QSYGETPH.htm , and http://publib.boulder.ibm.com/pubs/h...s/QSYRLSPH.htm . The Get Profile Handle API will take a user-ID and a password, verify the password and then return a profile handle. Ed Fishel

[Guest.Visitor]

Wade - You might look into the CHKPWD command if you are writing CL and only want to verify that the correct password was entered. I would be very careful with the security of the program itself, though. HTH, Steve

[Guest.Visitor]

Check out the January Security Patrol column in MC. There is a program there that uses the QSYGETPH and QWTSETP API's to do what you want to do. jte

[Guest.Visitor]

John, I'm testing the API's QSYGETPH, QWTSETP and QSYRLSPH by calling a utility CL program that initially gets the profile handle and swaps the profile. I then do some processing in my main CL program and then call the CL program again to release the same handle (via a parm) with QSYRLSPH. The problem is that when my main CL program is finished, my signon user profile is not the current profile. Isn't QSYRLSPH supposed to "unswap" the profiles for me? Or do I need to "unswap" the profiles myself with additional calls to QSYGETPH and QWTSETP? Thanks Chris Ringer

[flensburg@novasol.dk]

Hello Chris, You have to save the original user's handle and explicitly swap back to it, here's an example: http://publib.boulder.ibm.com/cgi-bi.../QB3APD03/A.22 Best regards, Carsten Flensburg

[Guest.Visitor]

Perhaps, I should explain my situation... As far as I know, the IFS does not support adopted authority but I have users that need to copy/delete/rename files in IFS folders where the users ordinarily only have *Read authority. I can meet this demand by temporarily swapping profiles for the interactive job (needs to be done interactively, not in batch). Does anyone have a better idea? Thanks. Chris Ringer

[Guest.Visitor]

You are correct about the Integrated File System not using adopted authorities as we conventionally associate them with a program. In V4R5 there are however new Unix-type APIs that provide many of these types of functions. Check out the various Set group ID, Set effective group ID, Set effective user ID, etc. APIs found in the Integrated File System APIs category.

[flensburg@novasol.dk]

Hello Bruce, Is the CPYFRMSTMF command included in the non-adopting IFS security setup? Currently I have a problem where a program adopting *ALL authority to the target file gets a CPFA09C exception when issuing a CPYFRMTSTMF command. If I change the file's *PUBLIC authority to *USE or give the user *USE private authority to the file the command works fine. If I then remove adoption from the program it fails again - *USE is of course not enough to replace the member. And that's what puzzles me - the adopted *ALL authority is only providing *CHANGE plus *OBJMGT access in conjunction with a public or private *USE authority to the file? Best regards, Carsten Flensburg

[Guest.Visitor]

I can fully understand your puzzlement on this. What's happening is that CPYFRMSTMF is using traditional file interfaces to the target file, and so while the Integrated File System command is not using the adopted authority, the underlying implementation of traditional data management (that is called) is. Normally we don't see implementation details like this surface to the user, but this is an unfortunate exception to that general rule. Whether this would be considered a bug or a feature I'm not sure.