|
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
