|
Well, this seems to explain it, except for the fact that the program--
works on one group profile but not the other.
I'll go over this doc again and maybe it will hit me.
Thanks for the link.
Mike
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Paul Roy
Sent: Friday, August 21, 2015 10:41 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: [Bulk] possible pgm adoption issue
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
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.
to a Group Profile. The Group Profile is a supplemental group.
The program uses adopted authority.
Program is receiving an error on the CRTUSRPRF stating not authorized
program on a different user that uses a different Group Profile. This
While trying to diagnose the problem, I had the operator run this
time the program worked.
owned by QSECOFR with *public Exclude and with *GROUP QSECOFR.
I have checked the authority on both of the group profiles. Both
are
list of users with authority. In both cases the Profile being copied
I cannot find any difference in these 2 Group Profiles other than
the
also has authority to the Group Profile.
either of these Group Profiles.
The operator running the program does not have specific authority to
specifically for this 1 Group Profile.
The CRTUSRPRF is being executed via a QCMDEXC in an RPGLE program.
It appears Adoption is working up to the point of the CRTUSRPRF
confidential and privileged communication. If you have received this
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
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.
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
