Correct me if I am wrong, but the proper way to secure
this object would
be to have
*public with *exclude, "/Serviceprofile/" with *all (or as
needed) and
then do a
CHGPGM /pgmname/ USRPRF(*owner) to adopt the service
profiles authority.
Then do a CHGOBJOWN OBJ(/pgmname/) OBJTYPE(*PGM)
which will make the owner of the program the service

If you accuse me of being a stickler for detail on this point, I'll
accept the charge, but I would characterize the authorization scheme you
have outlined here is an "adopted authority" scheme rather than an
"object authority" scheme.  To me an object authority scheme is one
where all users of a file are granted authority to that file either
directly, through one of their group profiles, or via an authorization
list, and an adopted authority scheme is one where no users are allowed
direct access to the data unless they go through an approved interface,
and that interface is able to provide the requisite authority to get the
job done.  

I like, and use, adopted authority schemes.  But I don't think they are
the same thing as object authority (maybe that is just my own semantic
bugaboo).  I'm also aware of the limitation that threatens their
obsolescence (the fact that adopted authority is not supported in file
systems other than QSYS.LIB).  Most of the newer web based applications
are use objects in file systems other than QSYS.LIB, so a traditional
adopted authority scheme will not be effective.  

And this is the point that leaves me confused about the whole "object
level security" promotion.  Most of the folks that I have heard promote
OLS as "the correct way" to do secure a System i, don't really mean OLS,
they mean "adopted authority".  But adopted authority has a serious
shortcoming that limits it's usefulness in the file systems that the
majority of new applications would use. 


John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
Celebrating our 10th Anniversary Year!

This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.