Re: Object authority

Consideration to using authorization lists across the application should be
given as well. Authorization lists can make the entire scheme somewhat
easier if you think it through before implementation.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Mon, Jun 13, 2022 at 8:52 AM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Hi, John,

I do not think you should need to "... rewrite security on the machine."

It should require only a few carefully thought out (and then tested)
"adjustments" to the current set-up.

For example, for those few programs that issue ADDPFM, RMVM or RNMM, just
ensure those *PGMs are owned by the "application owner" and that
application owner also owns the library containing those files, and the
*FILE objects in that library, and ensure that those programs are compiled
with USRPRF(*OWNER) so they adopt owner authority.

It should be possible to do this without disturbing much else.

Of course, testing is necessary. It is fortunate that you have a
"test-bed" or "sand-box" system in your basement, so you can set up a
subset of the actual "live" environment, with perhaps a few representative
"users" and test each proposed change, one by one, to ensure there are no
adverse impacts or unintended consequences.

Also, you really should become very familiar with IBM i security and
authorization, as you said you are developing a "change management"
toolset. Ideally, a change management product, properly implemented,
should automatically enforce and support such "good practices," while
preventing developers from bypassing the established "rules" of proper
change management.

Let me know if you have any other questions, or if I can offer some added
assistance.

All the best,
Mark S. Waterbury

On Friday, June 10, 2022, 06:46:46 PM EDT, <
smith5646midrange@xxxxxxxxx> wrote:

I appreciate all of the input that I have gotten but I am not looking to
rewrite the security on the machine.

I am looking for a very specific solution of that blocks the manipulation
of
objects (creating, deleting, renaming) while still allowing the use of
member commands like ADDPFM, RNMM, and RMVM.

It appears that IBM has tied the execution of the member commands to the
authority of the file AND LIBRARY which makes no sense to me. I was sure
that I was missing something in the combination but it does not appear that
I am.

And to further clarify, I am trying to prevent the developers from screwing
up their own environment which is breaking the testing for other
developers.
It is stupid stuff like the renaming a PF and creating a new one but not
changing the logicals so they are still pointing to the old file. The
change management software handles this so if they used it, there wouldn't
be a problem.

Production is a whole other story that I don't have the energy to fight so
I'm not going to bother. Besides, they will get reprimanded for breaking
production but nobody cares if they break the test environments.