Re: [Bulk] possible pgm adoption issue -- MIDRANGE-L

If you still need an explanation for the difference between "adopted authority" and "profile handle"

Adopted authority is only active until the program with USRPRF(*OWNER) ends. It's a temporary thing... and it doesn't really "switch" to the new user, but rather when authority is checked, it will check both your profile and the owner's profile, and use whichever has the higher authority. So if your profile doesn't have authority to something, but the owner's profile does, you get access.. but also if the owner's profile doesn't have access, but your signed-in profile does, you also get access. Under adopted authority if you use RTVJOBA CURUSR(&USER) or retrieve the current user (not the original job user, but the current user) in RPG or whatever, you will still get your signed-in user profile... the *OWNER profile isn't really "signed in".

So adopted authority is, IMHO, the one that should give you a headache, because it's very complicated. You aren't really switching to another userid... just sort of adopting it's authority, and only if your profile doesn't have authority. No other computer platform that I've ever seen has something like adopted authority.. just IBM i.

On the other hand, profile swapping (with the profile handle or profile token APIs) actually changes which user is the current user signed in. If you switch from userid "MikeSmith" to userid "JohnDoe" you will only have JohnDoe's authority. If MikeSmith has authority to something, but JohnDoe doesn't, you won't get authority because you're no longer MikeSmith, you're completely JohnDoe. Likewise, if you retrieve the current user (again, the current one vs. the original job one) profile, it'll show JohnDoe... your job is completely considered to be JohnDoe at this point. Just like if you signed on as JohnDoe to begin with.

IMHO, this second concept is very simple -- you're just using another profile instead of the original one. Though, of course, the coding is trickier since it requires APIs instead of simply putting USRPRF(*OWNER) on a program.

The other thing with profile swapping is you need to make sure that no matter what happens, the program runs the code to swap the profile back. Otherwise this could be a big security problem. For example, if the operator who uses your program can find a way to crash the program so that it never swaps back to the original userid, they'll find themselves signed on as QSECOFR, and will be able to do whatever they want as that profile. Likewise, if the code is debuggable, they could potentially use a debugger to change variables in your code so that it never swaps back... so this is an area where it's really easy to introduce a security hole. Be careful to make sure you monitor for all possible errors and swap the profiles back before the program ends. Or use stuff like CEERTX or CEE4RAGE to guarantee that you are able to swap back. If an error occurs while trying to swap back, don't just print a message and end your program -- end the entire job to make sure that the user doesn't get a command-line with elevated authorities.

Sorry if that sounds severe -- doing this right is very doable, but I want to make sure that you're taking that possibility into account.

On 8/21/2015 12:55 PM, Smith, Mike wrote:

Well now that I have this solved, I'm not going to try and hurt my brain by looking at this now. I'll save this for another day.

Thanks

Mike

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, August 21, 2015 11:47 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: [Bulk] possible pgm adoption issue

No, actually I cannot give a simple explanation of the profile handles. I don't suppose you'd buy the simple "used for those cases when adopting authority won't work, like stream file access. Just take it on faith."?

I can give this comparison. When you do a WRKACTJOB you may see some Netserver type jobs running under some IBM user. And the joblog may say "Now servicing user profile SMITTY" or some such thing? Newer versions of the OS show "Current User" on WRKACTJOB versus job user. These would show SMITTY instead. Sample
Current
Subsystem/Job User
QPWFSERVSO CRAIGS
Job: QPWFSERVSO User: QUSER Number: 020103
Servicing user profile CRAIGS from client gdl192.dekko-1.

See also:
Get Profile Handle (QSYGETPH)
Release Profile Handle (QSYRLSPH
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/sec1.htm?lang=en-us

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: "Smith, Mike" <Mike_Smith@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/21/2015 11:19 AM
Subject: RE: [Bulk] possible pgm adoption issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

Could you give a simple explanation the Profile handles? I am not
really familiar with them or how to use them.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Friday, August 21, 2015 10:55 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: [Bulk] possible pgm adoption issue

Would the profile handles be an appropriate workaround?
Otherwise you can submit a job that runs under the owner of that program
and it should work.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Paul Roy <paul.roy@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/21/2015 10:40 AM
Subject: RE: [Bulk] possible pgm adoption issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

There is some restriction when using CRTUSRPRF and CHGUSRPRF with adopted
authority

some documentation here

http://www-01.ibm.com/support/docview.wss?uid=nas8N1013328

Kind Regards,
Paul

From: "Smith, Mike" <Mike_Smith@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 21/08/2015 15:51
Subject: RE: [Bulk] possible pgm adoption issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

2 programs involved. 1 Cl and 1 SQLRPGLE.
Both have USRPRF(*OWNER) and owner is QSECOFR
Cl calls the SQLRPGLE.
I know you have to be careful on a SQLRPGLE and change the owner on the
compile.
The SQLRPGLE executes a command via QCMDEXC to CRTUSRPRF. The majority of

the parms are retrieved via a RTVUSRPRF command.
The CRTUSRPRF fails with not authorized to a Group Profile.

In trying to resolve, I created a new user from an existing user that has
a different Group Profile. This was successful.
Which would seem to indicate a difference in the Group Profiles. However
both are owned by QSECOFR with *public *exclude and a Group of QSECOFR.
They appear to be identical in their authority.

Mike
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Friday, August 21, 2015 9:29 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: [Bulk] possible pgm adoption issue

USRPRF(*OWNER) and USEADPT(*YES) are two unrelated things. Well maybe not

unrelated but it makes no sense for a program to have both.

USRPRF(*OWNER) says to not use the authority of the user currently running

the program but to adopt the authority of the person who owns this program

instead.
USEADPT(*YES) says if there is an unbroken chain of USEADPT(*YES)
throughout the call stack all the way up to some program which does
USRPRF(*OWNER) then to use that adopted authority. For example, let's say

you have an intitial program called BPCSMENU and it is owned by SSA and it

has USRPRF(*OWNER). BPCSMENU calls PGMA owned by SMITTY which has
USRPRF(*USER) USEADPT(*YES) then it will continue to use the adopted
authority of SSA. If PGMA calls PGMB then this chain continues until the
first program that has USEADPT(*NO).

But, yes, I would check for the presence of one or the other of these.

There are some scenarios in which adopting authority does no good. Mainly

accessing data in the stream file system outside of the /qsys.lib system.
This will require using the profile handle APIs.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Paul Roy <paul.roy@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/21/2015 08:50 AM
Subject: RE: [Bulk] possible pgm adoption issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

does the DSPPGM shows USRPRF (*OWNER) or USEADPT(*YES) ?

Cordialement, Kind Regards,
Merci, thank you,
Paul

From: "Smith, Mike" <Mike_Smith@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 20/08/2015 18:03
Subject: RE: [Bulk] possible pgm adoption issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

The program is owned by QSECOFR.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Mark S Waterbury
Sent: Thursday, August 20, 2015 12:01 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: [Bulk] possible pgm adoption issue

Mike:

What profile owns this program, and thus, is the profile that it adopts
authority from? What authority does that user profile have?

Mark S. Waterbury

> On 8/20/2015 11:41 AM, Smith, Mike wrote:

We have a program that an operator uses when setting up a new user. It

basically does a RTVUSRPRF on an existing user and then issues a CRTUSRPRF

on the new user with values from the existing user. This has been used
for years, but I'm running into an issue this morning.

The program uses adopted authority.

Program is receiving an error on the CRTUSRPRF stating not authorized

to a Group Profile. The Group Profile is a supplemental group.

While trying to diagnose the problem, I had the operator run this

program on a different user that uses a different Group Profile. This
time the program worked.

I have checked the authority on both of the group profiles. Both are

owned by QSECOFR with *public Exclude and with *GROUP QSECOFR.

I cannot find any difference in these 2 Group Profiles other than the

list of users with authority. In both cases the Profile being copied
also has authority to the Group Profile.

The operator running the program does not have specific authority to

either of these Group Profiles.

The CRTUSRPRF is being executed via a QCMDEXC in an RPGLE program.

It appears Adoption is working up to the point of the CRTUSRPRF

specifically for this 1 Group Profile.

I feeling like I'm missing something simple, but I'm not sure what.

Any ideas?

Mike

NOTICE: This message, including any attachment, is intended as a

confidential and privileged communication. If you have received this
message in error, or are not the named recipient(s), please immediately
notify the sender and delete this message.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

NOTICE: This message, including any attachment, is intended as a
confidential and privileged communication. If you have received this
message in error, or are not the named recipient(s), please immediately
notify the sender and delete this message.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

NOTICE: This message, including any attachment, is intended as a
confidential and privileged communication. If you have received this
message in error, or are not the named recipient(s), please immediately
notify the sender and delete this message.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

NOTICE: This message, including any attachment, is intended as a confidential and privileged communication. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this message.