Re: IFS - QDLS security dilemma on the 400 -- MIDRANGE-L

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  / \
--------------------------------------------------------------------