Re: IFS ownership

[Mark Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>]

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@xxxxxxxxx>
wrote:

> 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?