RE: Dumb adopted authority question

midrange-l-request@xxxxxxxxxxxx wrote:

>   2. Dumb adopted authority question (David Gibbs)
>
>If I am signed on as QSECOFR, and run a program (ILE CL) that is owned 
>by a normal user and has USRPRF(*OWNER), what is the programs effective 
>authority?  QSECOFR or the users?
>
>I've got a program that is being run as QSECOFR, but the USRPRF value is 
>that of a normal user ... the program is failing when it's trying to 
>switch profile handles to another *SECOFR profile because it does not 
>have *USE authority to QSECOFR.

David:

Hardly a dumb question at all. For a start, it's not clear where the problem is 
-- when the program is switching QSECOFR to the new current user or when it's 
trying to return that current user to QSECOFR. (It seems you're sure it happens 
on the initial switch.)

Beyond that, I have been led to believe that program adopted authority only 
becomes effective if and when the job current user does not have sufficient 
authority. That is, there are ways to think of it as 'alternative' authority 
rather than 'cumulative' authority. This becomes partly visible when a program 
that is compiled as USRPRF(*OWNER) displays some object authority and the 
displayed authority shows as [*ADOPTED]; I think that value appears _only_ when 
the program owner's authority is required to access the object authorities. If 
current user has sufficient authority, that value won't appear, i.e., program 
adopted authority isn't actually in effect for that object at that time. (ICBW)

Now, AFAIK, QSECOFR special authorities cannot be changed (Svalgaardisms 
notwithstanding, etc.) and *ALLOBJ short-circuits user authority checking for 
an object. Hence, it would seem that the problem ought to be at a point after 
the first profile swap has taken place. I.e., QSECOFR authority should be 
sufficient, regardless of USRPRF(*OWNER), to swap to some other profile.

At least, "should be" are the words I use. If that isn't happening, I'd send 
the question to IBM and expect them to fix it. Except...

As has been mentioned in other posts, there are indeed issues with profiles 
created back in V2 and earlier. I've seen where these kinds of problems are 
fixed by recreating profiles. As of yet, I haven't seen this to be true for 
QSECOFR; but that might only be luck.

Tom Liotta

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp