Re: IFS - QDLS security dilemma on the 400

You could use IBM OS/400 APIs: QSYGETPH, QSYSETP and QSYRLSPH
to temporarily change the current job to run under another *USRPRF, since
the
IFS ignores "adopted authority"... (e.g. change to the user profile that you
want
to be the "owner" of the files in QDLS and/or in the IFS).

----- Original Message -----
> From: "CZE Midrange" <CZEMidrange@xxxxxxxxxx>
> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> Cc: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> Sent: Saturday, February 28, 2004 5:08 AM
> Subject: Re: IFS - QDLS security dilemma on the 400
>
> CPFA09C is exactly the error message!
> But alas...PGP on all objects = *none.
>
> The plot sickens.
>
> Basically, how do you ensure that a file gets *RWX authority on it when it
> is created in the IFS?
>
>
> -----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
>
> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> From: Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> Date: 02/27/2004 11:19PM
> Subject: Re: IFS - QDLS security dilemma on the 400
>
>
> On Saturday, February 28, 2004, at 12:18  PM, CZE Midrange wrote:
>
> > All of the RPG and CLP programs were compiled under *OWNER and by the
> > same
> > person who is running the application to make the .xls file. The input
> > work
> > file that is fed to the java routine is also under the same user
> > although
> > originally it was created under a test profile...the object ownership
> > was
> > changed to the principle user though with chgobjown command.
>
> Adopted authority is ignored for any IFS operation.
>
> > The EXCEL directory in the IFS root has public *all. The QDLS
> > directory was
> > given public *all and the freaking QDLS/EXCEL folder was given...you
> > guessed it...public *all. When the .xls file is first created, the
> > rights
> > assigned to it by OS400 are *RW...and naturally when copied to
> > QDLS/EXCEL
> > it carries the same. It seems to need *RWX but it will not happen.
> > When I
> > do a wrklnk to try and delete both the IFS and QDLS version of the
> > files,
> > the IFS lets my usrprf do it but the QDLS will not! However, it lets
> > the
> > test profile do it! Where is it grabbing that?  Did the chgobjown do
> > something funky?
>
> I've been through something similar with CPY. The authorities on the
> source and target directories and files met the criteria specified in
> the Security Reference but still the copy failed. I eventually
> determined that it was caused by the objects having a Primary Group
> Profile (PGP). The user doing the copy was a member of group X. The PGP
> was group Z. Even though both *PUBLIC and group X had sufficient
> authority to perform the copy it failed with the woefully inadequate
> CPFA09C Not authorised to object. It appears that once a PGP is added
> to a directory or stream file object (and possibly a QSYS.LIB object
> too) the normal OS/400 group authority is stuffed.
>
> If I removed the PGP Z from the objects the copy worked (via *PUBLIC or
> group X authority)
>
> If I removed group X authority the copy worked (via *PUBLIC authority)
>
> I'm not sure if this is broken behaviour or working as designed but I
> could not find it documented anywhere. Perhaps this is your problem too?
>
> I wish there were more consistency between the native and foreign
> interfaces. In many cases the native CPY command will fail an authority
> test but start QSH and the cp command will work quite happily.
>
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
>    FlyByNight Software         AS/400 Technical Specialists
>
>     http://www.flybynight.com.au/
>    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>    Fax:   +61 3 9419 0175                                   \ /
>                                                              X
>                  ASCII Ribbon campaign against HTML E-Mail  / \
> --------------------------------------------------------------------
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>  Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l .
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>