Re: Do I understand USRPRF *OWNER USEADPAUT *YES correctly? -- MIDRANGE-L

Thanks Charles (and Don) for the clarification on the USEADPAUT. That explains something else I had a problem with.....

But going back to your question about "What am I doing?"...

If we just issue a standard JDBC connection the iSeries, we have a couple of problems (at least, I think so...)

1. No overrides are set (we have multiple membered files and creating alias's is a needless hassle when we can just override the files). So we have to set overrides. 2. We have some authority issues to deal with. The user profile used in the JDBC connection may not have authority to the files/libraries in the application.

If we connect to the iSeries, we get a persistent QZDASOINIT job as long as the connection exists. That is a good thing because we are pooling connections. So, once the connection is established, we just call the program that sets the overrides and, since the program is properly owned, those overrides persist with the correct authority as long as the connection is in place. Cool! That is just what we want because the servlet(s) need to access the data. The pooling mechanism we wrote is "smart" enough recognize when the member requirements or library list has changed and when they do change, we create a new pool entry and call a program that sets the new overrides.

It was the override/authority issue we wanted to solve. Since the program, called at the time of the JDBC connection, sets the overrides and is properly owned, everything is good. We were running into issues where we were getting "Not authorized to file XXXXX" messages and I *think* it was because the CL program we called to set the overrides was set to *USER rather than *OWNER. I'll know as soon as I stop Tomcat and shoot the JDBC pooled connections and restart.

We haven't yet gone to a three tiered solution yet: Java ---> stored procedures --> database. It adds some additional work up front that we haven't had time to do and since the bulk of the work I do is at 30,000 feet (while traveling), writing programs and testing them in Linux is much easier in the Java --> database realm. I can run them against MySQL while I write and test and then deploy the WAR file when I get home and I am done. (OK, there is some laziness there....).

Thanks again on the USEADPAUT tip....I need to change a couple of programs and test this....

Pete


Wilt, Charles wrote:

Pete,
Your correct about USRPRF(*OWNER).   That causes the program to adopt the 
authority of program's owner.
However, you are misunderstanding USEADPAUT.  This controls rather a program 
will use authority adopted at some prior call level.  Let me give you an easy 
to understand example.
Say you have a program (PGM1) that is USRPRF(*OWNER) owned by QSECOFR that 
calls QCMD.
From the resulting command line, if you call another program (PGM2) that is USRPRF(*USER), what authority is use?
If USEADPAUT(*YES) on PGM2, then QSECOFR authority is used via the prior 
adoption
If USEADPAUT(*NO) on PGM2, then only the users actual authority is used.
Now, as too your Java stuff.  I don't understand what you are doing.  You 
say you are calling a program that provides access.  What does this program do? 
 You talk about file overrides, but I don't know of any way for that to affect 
authority used by the JDBC connection.
To control access via JDBC in the same manner that you are controlling it via 
green screen, ie. application only access.  You're JDBC shouldn't be accessing 
a file directly.  Instead all access would need to be through stored procedures.
HTH,
Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Helgren
Sent: Friday, April 08, 2005 10:36 AM
To: Midrange Mailing List
Subject: Do I understand USRPRF *OWNER USEADPAUT *YES correctly?
I have been operating under the some assumptions about adopted authority that have been recently challenged and I want to make sure I haven't missed something.

We have all the files in a library set to allow a specific user profile to have *ALL authority (lets call it FUSER) and *PUBLIC authority set to *EXCLUDE. All of the programs that access the files are owned by FUSER and the authority of those programs is set to USRPRF(*OWNER) and USEADPAUT(*YES). As far as I know that prevents anyone from accessing these files outside of using specific programs unless they have *ALLOBJ authority (Correct?)

We need to access those same files through JDBC so we have a program that we call when we establish the connection in Java that sets the library list and file overrides (OVRSCOPE (*JOB)). That program is also owned by FUSER and is compiled USRPRF(*OWNER) and USEADPAUT(*YES). This should prevent anyone who successfully connects through JDBC but doesn't call the program from getting access to the files (unless they have *ALLOBJ authority) (Correct?)

There are a dozen other things we do to secure the access but the thing I am most interested in is making sure the files ARE accessible through this method. If the OVRSCOPE is *JOB and the program is owned by FUSER and FUSER has *ALL authority then the tables should be available to the Java program as long as the job (connection) is active (correct?)
Pete Helgren
-- 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.