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



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.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
vforbes@xxxxxxxxx
Sent: Friday, June 10, 2022 11:49 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Object authority

The best method is having production on one box/partition & development on
another.

Adopting authority programs should not be needed.

This is one method of setting security.  This may not be complete, but it is
a start.

Create new 'Group' user profiles.  APPUSER, APPOWNER, PGMR.  These ids have
no password & cannot sign on.
Change developers to be part of the Grpprf PGMR, App users to the Grpprf
APPUSER Create an AUTL (authorization lists).  I.e. PROD
    Add PGMR to this Autl with only *USE access if you want problem
support or *NONE if you don't want them to even see it.
    Add APPUSER to this Autl with either *CHANGE or *ALL access.  You
need to test this.
Revoke *ALL authority to *ALL users to all 'Production' objects & libs.
Leave IBM libs alone.  Do this after hours.
Change the owner of all 'Production' objects & libs to a new id APPOWNER
Grant authority to all 'Production' objects & libs to the Autl PROD.  Any
future authority changes are done in the Autl.  I.e. adding a 'FireFight'
id.

Make a copy of production libs for developers. 
Create new Autl DEV
    Add PGMR to this list with only *CHANGE or *ALL access Restore prod
libs to new names Change obj & lib Autl to new Autl DEV Optional, you may
want to create a 'Sterilization' program to mask things like account SIN,
name, address etc.

Vincent

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
dr2@xxxxxxxx
Sent: June 9, 2022 3:40 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Object authority

Among other things I would look at using programmes that adopt
authority...and firing a few programmers....

On 2022-06-09 14:42, smith5646midrange@xxxxxxxxx wrote:

We are having problems with developers "installing" new objects
outside of the change management software and also renaming existing
objects and creating new versions of them.

We are an IP based company so we rely heavily on adding and removing
PF and LF members.

Is there a level of security that I am overlooking that will allow us
to lock down a library to prevent the creation of new objects and the
renaming of existing objects yet still allow the ADDPFM/ADDLFM and
RMVM
commands?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.