Re: Failure to adopt authority -- MIDRANGE-L

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