Re: IFS object ownership

James

Adopted authority is not the same as swapping profiles with handles - the latter works with the IFS, the former does not.

Also, be very careful not to exceed the number of entries for a profile owning objects, as well as private authorities to objects the user owns. That is why IBM recommend not having a single user own everything. See Chapter 5 of Security Reference and the help for PRTPRGINT.

Vern

On 10/12/2010 7:52 PM, James H. H. Lampert wrote:

Mark said:

You can also use QWTSETP (set profile handle) and QSYGETPH (get profile
handle) to swap to the profile you want to own the IFS files, before
your program creates them. This technique avoids having to use chown
(or equivalent) after the fact. If your application ships with or
installs an application owning profile, you could change to that
profile, so that all IFS files created by this application are owned by
that profile.

Well, chgown() says explicitly that it doesn't use adopted authority,
and I've determined empirically that the CL CHGOWN command apparently
doesn't use adopted authority (including *OWNER authority), either. So
"no joy" on transferring the IFS objects to an IBM-supplied user
profile. It looks like an "owning profile" might be at least part of the
answer. But probably not by swapping profiles; I believe that requires a
password at least to swap out, (maybe also to swap back?).

Hmm. IDEA: Suppose we give public *ADD authority to the application's
administrative user profile. Then, we could either get that profile's
user number at program-launch, and either chown or fchown the IFS object
on creation, or we could simply (since this is happening in C) shell out
a CHGOWN command on IFS object creation (I wonder which option has the
least overhead).

--
JHHL