× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Tom,

I would agree with your definition of adopted authority. In addition to
a profile swap, you can set effective user/group/groups as long as you
are on V5R2 or later and is the preferred approach. 

--David Morris

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of
qsrvbas@xxxxxxxxxxxx
Sent: Thursday, September 07, 2006 4:06 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

David.Morris wrote:

In your original message you said:

"I would use adopted authority for access through the expected
application interfaces and use proxy commands to limit the use of EDTF
or DFU to well-defined views of the data, then take away the data
rights
to the file. The object authority is still checked on the remote
server
interfaces. If you need access to the file from one or more remote
servers, you can use exit programs to give you this authority."

I took that to mean that you used adopted authority in your exit
program
but it sounds like you are actually swapping or setting the effective
user, which is the approach I use in all cases where I used to use
adoption. There are some other steps you need to take like register
exits to back out the authority to mimic adoption.

Now there's an interesting point to discuss...

One item that is needed is a clear agreement on terms. "Adopted 
authority" is used in ways that seem to mean different things to 
different people at different times. I have had a personal understanding

that limits its meaning, and maybe others could comment so that a 
consensus is reached and available.

To me, "adopted authority" refers specifically to the authority gained 
by a program that has the USRPRF(*OWNER) attribute set. It does _not_ 
refer to any authority resulting from the use of any profile-switching 
APIs. "Adopted authority" becomes active when, within the program, an 
object access is attempted and the job current user does not have 
sufficient authority but (1) the program USRPRF(*OWNER) attribute is set

and (2) the program owner does have sufficient authority.

One result is that the USEADPAUT(*YES/*NO) program attribute _only_ 
affects the authority gained within a higher program in the call stack 
by the above mechanism. It has no effect on authority gained by a 
profile switch from any API because that isn't "adopted authority".

Anybody have modifications (or direct corrections) to add?

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.