|
Hi, Rob,
You could also achieve your goal, for new documents and folders created in
the IFS, by journaling the relevant IFS directories and then have a
"monitor" job that scrapes the audit journal for messages -- that way, you
can have it call a program whenever a new file or folder is added, to issue
the relevant desired CHGOWN and CHGAUT commands, etc. Carsten Flensburg's
QTIPSRC has examples of this kind of thing.
As for "performance" you get the best performance by avoiding any extra
"private" authorities and ensuring that all objects needed by various
groups of users are owned by the proper group profile. The "fast path" for
OS/400 or IBM i object access at the MI layer is to have an object that is
owned by one user profile, and the only other access is for *PUBLIC, either
*USE or *EXCLUDE, etc., as needed.
I don't think authorization lists should slow down those back-ups, but I
think it is more likely due to having multiple user profiles listed in the
object's private authorities. DSPAUT will show you for IFS, or for the
QSYS.LIB stuff, DSPOBJAUT.
Hope that helps (somewhat).
All the best,
Mark S. Waterbury
On Friday, February 28, 2025 at 09:02:53 AM EST, Rob Berendt <robertowenberendt@xxxxxxxxx> wrote:
I was hoping for an IFS version of
CHGLIB LIB(MYLIB) CRTAUT(MYAUTL)
The alternative is:
CHGAUT OBJ('/mydir') AUTL(MYAUTL) SUBTREE(*ALL)
CHGAUT OBJ('/mydir') USER(*PUBLIC) DTAAUT(*AUTL) OBJAUT(*NONE)
CHGOWN OBJ('/mydir') NEWOWN(OWNPRF) RVKOLDAUT(*YES)
SUBTREE(*ALL)
Assuming that the users revoked with RVKOLDAUT are in the authorization
list, if needed.
Then there's revoking users who have individual authority, but not
ownership. They should be in the authorization list instead.
In this example, the individuals listed below should be in the
authorization listed instead:
Data
User Authority
*PUBLIC *RX
ROB *RWX
OTHERGUY *RWX
To remove OTHERGUY:
CHGAUT OBJ('/mydir') USER(OTHERGUY) DTAAUT(*NONE)
OBJAUT(*NONE) SUBTREE(*ALL)
Do not confuse *NONE with *EXCLUDE. *NONE just removes their individual
listing and then relies on *PUBLIC and the authorization list, (if there).
*EXCLUDE is used to deny them access and can be overridden if they have an
individual listing in the authorization list.
I see a lot of directories where the *PUBLIC is *RWX. Listing individuals
with the same authority is solely there to kill performance.
I also have to clean up the traditional or /qsys.lib stuff.
Having individuals listed instead of using an authorization list can really
bog your system down. A SAVSECDTA should take 4 minutes, if it's taking
hours it's because your 'private authorities' are messed up this way. I've
had this on more than one system.
On Thu, Feb 27, 2025 at 5:36 PM Rob Berendt <robertowenberendt@xxxxxxxxxwrote:
Is there any way to say any new object created in this directory should--
have the same owner as the owner of the directory?
Is there any way to say any new object created in this directory should
have the same authorization list as the directory itself?
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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
