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



James H. H. Lampert wrote:

>Al Barsa wrote:
>>
>> There are very valid reasons to specify USRPRF(*OWNER).  For example:  I
>> want a user to be able to add a member to a file, but I don't want
*PUBLIC
>> to have either that authority in their profile or to the file.
>
>There are also very valid reasons for commercial products to be shipped
>not only with USRPRF(*OWNER), but with QSYS as the owner. Case in point,
>QuestView (and its younger sister, ThinView) both call the Create
>Program API, which is normally owned by QSYS with PUBLIC *EXCLUDE. If
>our products didn't ship with the programs that call the API set up that
>way, NOBODY without near-QSECOFR-equivalent authorities would be able to
>create VIEW programs.

I agree with you that there are valid reasons for commercial products to be
shipped with USRPRF(*OWNER). I wish you would have used a better example.
First, the Create Program (QPRCRTPG) API is shipped with public *USE
authority. Second, adopting QSYS authority just to guarantee access to a
few commands and APIs is adopting more authority than is needed.

The guidelines I recommend for using adopted authority is to minimize the
amount of authority that is needed, and minimize the length of time that
the adopted authority is used. Following this guideline helps reduce the
risks associated with using adopted authority and helps produce a security
design that is crisp and easier to justify.

A better choice to adopting QSYS, QSECOFR, or any other user profile that
has lots of special authority, is to create a user profile for the
application that is disabled, has no password, and does not have any
special authority, or depending on the application has minimum special
authority. Then grant that profile private authority to the commands and
APIs needed by the application and make it the owner of the programs that
need to adopt that authority. With this design, the install exit (or setup)
program for the application is the only place that may need to adopt
something as powerful as QSYS or QSECOFR.

Please do not take this as an attack on your products. Other than what you
say above I do not know anything about them.

Ed Fishel,
edfishel@xxxxxxxxxx


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.