Re: Losing Authority to a file in Batch

[Ed Fishel <edfishel@xxxxxxxxxx>]

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