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 .