Re: BPCS- Adopted Authority

Hi JS,

What is the specific problem you are trying to solve? It depends upon how
you have set up BPCS, and if any modifications were done from the standard
way of doing BPCS security or not at your site.

The answers to adopted authority in general can be found in the AS/400
security manual, which is freely accessed on line. If the Adopt Authority is
*YES, the previous level authority is passed down the line to the next call
level of the program (ie, if you were given authority to file ABC at level
1, and call level 2 says Use Adopted Authority *YES, then you get whatever
authority you were granted at level1, and can still access file ABC even if
the call level 2 program would not under other circumstances allow you to
access this file).

The ever-friendly AS/400 F1 help on DSPPGM explains the basics:

:        "        Use adopted authority - Help

 The value specified for the USEADPAUT option on the command used to change
the program.  This parameter  specifies whether program adopted authority
from previous  call levels is used (*YES) or not used (*NO) when this
program is running.   "                                     :

Another factor in this issue would be whose authority to the objects it
accesses is checked when any given program runs. It has to do with the
program compile setting of User Profile being either *OWNER or *USER, and
security checking for objects you will access in the program is done either
using the owner of the program, or the user using the program. If set to
*OWNER for example, you can have a program XYZ owned by GEORGE and files
owned by GEORGE, with PUBLIC authority set to *EXCLUDE on those files. A
user who is not part of the GEORGE group, but who had *USE authority to the
ZYZ program, when running the XYZ  program could change files owned by
GEORGE. But outside of that XYZ program, they would have no authority to
those same files - from a command line, for example, or SQL or DBU etc..

BPCS programs by default were all compiled with *USER and Use Adopted
Authority *YES at your release, and at all current BPCS releases except
6.1.01, where some programs were changed. In addition, by default, the SSA
user profile owns all BPCS objects, and users were instructed to use the SSA
group profile on all user profiles accessing BPCS so that everyone had
authority to BPCS programs and files. This means that even outside of BPCS,
users can also access the data files if the default security set up is used,
because of the SSA Group Profile setting on the AS/400 user profile. Even if
they do not have an AS/400 command line, a user with a PC using ODBC could
alter data in the BPCS files in this set up.

In version 6 releases of BPCS, there is a BMR that you can obtain for the
unobservable security programs so they are compiled with *OWNER, and you can
change a few things in the environment to use more advanced locked down
security in BPCS so that when users are outside BPCS, they can not alter any
files and can only alter data via BPCS programs (not SQL or ODBC). See BMR
51582 and BMR 56678. There is a very long and important README for these
BMRS that explains the basic changes required to implement the improved
database security this method can offer. These programs are not available
for non-supported BPCS releases in any BMR. For version 6, the BMRs are
available from Helpline. The problem you will run into for sunset versions
of BPCS is that the security programs are non-observable, and CHGPGM to
change User Profile to *OWNER will not run against these programs. CHGPGM
works for any observable programs.

Depending upon what problem you are trying to resolve, you may be able to
change certain observable BPCS programs in order to resolve the issue you
are having, if you are not trying to lock down the whole environment. It can
get complicated if a custom menu calls QCMDEXEC down the line, for example.
This is set to use adopted authority of the previous program's call level.
Ensure if you are trying to lock down an environment that you do not
accidentally give a command line to users who are currently adopting more
authority than you would like them to have at a command line....or make sure
that you write a program which in turn calls QCAPCMD or QCMDEXEC and that
your program uses Adopt Authority *NO and User profile *USER, so that the
user profile's own authority is checked to the objects they try to access
from the command line, and authority is not adopted from a prior call level.

I am not sure if this is the problem you were having or trying to resolve,
but if you require the security programs changed to use these different
parameters for your older BPCS release, you can contact your SSA
representative or the SSA GDC center nearest your area and see if you can
contract them to provide this modification to you.

Thanks

Genyphyr Novak
SSA GT

----- Original Message -----
From: "J S" <jbpcs8@yahoo.com>
To: <BPCS-L@midrange.com>
Sent: Tuesday, December 12, 2000 8:24 PM
Subject: BPCS- Adopted Authority


> Hello All,
> We are having BPCS ver 4.03.
> How does AS/400 adopted authority work and how to
> disable adopted authority given by BPCS intial program
>
> ?
>
> Please help.
>
> Jigs
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
> +---
> | This is the BPCS Users Mailing List!
> | To submit a new message, send your mail to BPCS-L@midrange.com.
> | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: dasmussen@aol.com
> +---
>

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---