CZE Midrange | 28 Feb 02:18 2004

IFS - QDLS security dilemma on the 400


An application we wrote takes a normal database file and creates an EXCEL
.xls STMF into a directory on the IFS called EXCEL. The java program is
called from a central CLP to convert ebcdic to excel.

Once the .xls is created, the CLP executes a CPY command (parameters were,
at one time or another, *replace with *keep or *new) to create a version of
file into the QDLS directory, folder named EXCEL. This is done because our
e-mailing software requires the attachments to originate out of QDLS.

Problem we are having is in the CPY command...it keeps failing due to
authority problems and nobody has been able to figure out why.

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.

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?

Anyway, we are stuck as to why the cpy object will not replace what is
(Continue reading)

Simon Coulter | 28 Feb 05:19 2004
Picon

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?
(Continue reading)

CZE Midrange | 28 Feb 12:23 2004

RE: IFS - QDLS security dilemma on the 400

   the user is enrolled.
   -----midra= nge-l-bounces@... wrote: -----

   To: "'Midrange System= s Technical Discussion'" <midrange-l@...>
   From: "John Bra= ndt Sr." <pgmr@...>
   Sent by: midrange-l-bounces@...= ge.com
   Date: 02/27/2004 08:59PM
   Subject: RE: IFS - QDLS security dile= mma on the 400

   The user profile un= der which the CPY command is being executed must be
   in
   the system direct= ory. Do a WRKDIRE and see if the profile is there.

   John Brandt
   iS= tudio400.com

   -----Original Message-----
   From: Pete Hall [= mailto:pbhall@...= tech.net]
   Sent: Friday, February 27, 2004 7:37 PM
   To: Midrange Sy= stems Technical Discussion
   Subject: Re: IFS - QDLS security dilemma on t= he 400

   At 19:18 2/27/2004, Rick Rayburn wrote:
   >An applica= tion we wrote takes a normal database file and creates an
   EXCEL
   >.xls= STMF into a directory on the IFS called EXCEL. The java program is
   >= called from a central CLP to convert ebcdic to excel.
   >
   >Once t= he .xls is created, the CLP executes a CPY command (parameters
   were,
(Continue reading)

CZE Midrange | 28 Feb 12:55 2004

Re: IFS - QDLS security dilemma on the 400

   the option 14 reveals public *all.

   <F= ONT color=#990099>-----midrange-l-bounces@... wrote: -----
   <B= R>To: Midrange Systems Technical Discussion
<midrange-l@...   com>
   From: Pete Hall <pbhall@...>
   Sent by: midrang= e-l-bounces@...
   Date: 02/27/2004 08:37PM
   Subject: Re: IFS - = QDLS security dilemma on the 400

   A= t 19:18 2/27/2004, Rick Rayburn wrote:
   >An application we wrote takes= a normal database file and creates an
   EXCEL
   >.xls STMF into a direct= ory on the IFS called EXCEL. The java program is
   >called from a centr= al CLP to convert ebcdic to excel.
   >
   >Once the .xls is created,= the CLP executes a CPY command (parameters
   were,
   >at one time or ano= ther, *replace with *keep or *new) to create a
   version of
   >file into = the QDLS directory, folder named EXCEL. This is done because
   our
   >e-m= ailing software requires the attachments to originate out of QDLS.
   ><= BR>>Problem we are having is in the CPY command...it keeps failing due
   t= o
   >authority problems and nobody has been able to figure out why.
      Try doing a wrkflr, and option 14 (authority). As I recall, document <B   R>library objects (QDLS) have their
own version of object security, which
   I   think has little to do with OS400 security. BTW, I've been told that Q   DLS
   is going away very soon. I'm not sure if that's just doom and gloom= hype.
(Continue reading)

CZE Midrange | 28 Feb 13:08 2004

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

To: Midrange Systems Technical Discussion <midrange-l@...>
From: Simon Coulter <shc@...>
Sent by: midrange-l-bounces@...
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.
(Continue reading)

Mark S. Waterbury | 28 Feb 17:48 2004
Picon
Picon

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@...>
> To: "Midrange Systems Technical Discussion" <midrange-l@...>
> Cc: "Midrange Systems Technical Discussion" <midrange-l@...>
> 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@... wrote: -----
>
> To: Midrange Systems Technical Discussion <midrange-l@...>
> From: Simon Coulter <shc@...>
> Sent by: midrange-l-bounces@...
> Date: 02/27/2004 11:19PM
> Subject: Re: IFS - QDLS security dilemma on the 400
(Continue reading)

Simon Coulter | 28 Feb 13:32 2004
Picon

Re: IFS - QDLS security dilemma on the 400


On Saturday, February 28, 2004, at 11:08  PM, CZE Midrange wrote:

> CPFA09C is exactly the error message!
> But alas...PGP on all objects = *none.

Then check that the user has *X authority to all directories in the 
path to the file AND has *W authority to the directory in which the 
file is being created. You should open the Security Reference and 
search for the command you are using to perform the copy and then check 
that the authority listed in the reference matches the authorities 
found in the source and target paths.

> The plot sickens.
>
> Basically, how do you ensure that a file gets *RWX authority on it 
> when it
> is created in the IFS?

IFS objects are owned by the user who created the object.

The owner inherits the authority from the owner of the parent directory 
even if the two owners are different profiles.

*PUBLIC inherits the *PUBLIC authority from the parent directory.

Applications can override this behaviour by setting the mode mask in 
the job prior to creating the object. CPYTOSTMF sets *PUBLIC *NONE 
regardless of the parent directory authorities.

(Continue reading)


Gmane