× 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.



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.
> 
> 


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.