RE: Failure to adopt authority -- MIDRANGE-L

The function is used to archive an object and for reasons that aren't worth
going into but are required, it needs to be renamed when it gets archived
(kind of like how QRPLOBJ works but different naming strategy). The archive
name is a sequential "next up" naming pattern (AAAAAAAAAA, AAAAAAAAAB,
AAAAAAAAAC, etc.) If I rename the object first, eventually the new "next
up" name will exist in the from library. If I move it, eventually the old
name will exists as one of the "next up" named objects. The only way to
guarantee they will never to crash into each other is to move and rename it
at the same time.

I have since found out that there is an API named QLIRNMO that does the
rename and move of objects in one call so I will be altering my code again
to verify that it works as expected...with adopted authority.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Evan
Harris
Sent: Thursday, May 19, 2022 8:21 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Failure to adopt authority

Hi

I agree with your concerns somewhat about the profile handle, but I guess
what I wonder about is why it matters that MOV does it in one operation.
If the operation is being performed in a program then 2 commands vs 1 seems
likes like the wrong thing to be optimizing - particularly when it's driven
you to be using a security mechanism you are uncomfortable with.
Using the commands appropriate to the file system would have saved you the
security issue and avoids any other hidden surprises.
I'd be particularly interested in what the system catalog looks like after
the moves - probably OK, but makes me wonder.

On Fri, May 20, 2022 at 10:54 AM <smith5646midrange@xxxxxxxxx> wrote:

Thanks everyone for the feedback on this.

I walked away from this for a while to allow it to sink in and I will
be honest, the idea of using the profile handles for what I am doing
worries me.

Three reminders about the problem.
1) These are always objects, never actual "IFS files". I am only
using the IFS naming because of the MOV command.
2) I am using MOV because I need to move and rename the objects and
MOV lets me do this in one step without risking conflicts with either
name in either library.
3) The problem is that I don't have the authority that I need to the
object that I am issuing the MOV against and the IFS won't adopt
authority of the program doing the MOV.

After clearing my brain by eating some pizza, it hit me. The program
(which will end up adopting *ALLOBJ authority) will never try to MOV
an object that has authority granted to an individual profile (it will
always be controlled by the group profiles) so the work around that I
came up with is to grant *ALL to the executing profile, MOV the
object, and then revoke the authority from the profile.

So far, it is working fine.

Anybody know of any hidden eggs with this concept that I have not
stumbled over yet which would cause this to break?

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Rob Berendt
Sent: Thursday, May 19, 2022 3:39 PM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Failure to adopt authority

I believe QSECOFR.

Look at it this way. You connect to your system using a file share or
odbc.
The job user is QUSER or something like that. However if you create a
new file in that share you own it and not QUSER.
That job is using a profile handle to your user id.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
Mail
to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
smith5646midrange@xxxxxxxxx
Sent: Thursday, May 19, 2022 3:31 PM
To: 'Midrange Systems Technical Discussion'
<midrange-l@xxxxxxxxxxxxxxxxxx

Subject: RE: Failure to adopt authority

CAUTION: This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.

Because I'm being lazy and not wanting to create a test program to
find this answer...

If I am signed on as JSMITH and swap the profile handle to QSECOFR and
then create an object, is the object created by and/or owned by JSMITH
or QSECOFR?

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Mark Waterbury
Sent: Thursday, May 19, 2022 3:15 PM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Failure to adopt authority

This is most likely because the IFS "no workie" with adopted authority.

You need to use the QSYGETPH, QWTSETP and QSYRLSPH APIs to temporarily
change the current job to run "as" a user profile (like QSECOFR) that
has sufficient authority over the IFS directories and files in
question, because the IBM i IFS (Unix-like) APIs do not "adopt"
authority.

Note that you probably need to be adopting authority to have authority
to swap profiles, so you are half way there. :-)

Hope that helps,

Mark S. Waterbury

On Thursday, May 19, 2022, 03:05:27 PM EDT,
<smith5646midrange@xxxxxxxxx

wrote:

I have to be overlooking something and I'm hoping one of you will see it.

I have an SQLRPGLE program named SCRTEST. It is owned by QSECOFR and
is USRPRF(*OWNER);

In the program it needs to execute the below MOV command which is
built on the fly. FYI - I'm using MOV because I can rename the file
and move it to a different library at the same time.

MOV OBJ('/QSYS.LIB/OLDLIB.LIB/OLDFILE.FILE')
TOOBJ('/QSYS.LIB/NEWLIB.LIB/NEWFILE.FILE')

I have tried calls using both system() and QCMDEXC().

If I run the program with the QSECOFR profile, both versions work. If
I run it with a *USER profile, both versions fail.

What am I missing? Do system() and QCMDEXC() not pass the adopted
authority to the command that they call? If not, is there a different
command that does?

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com