RE: [Security400] object authority problem

[rob@xxxxxxxxx]

Thanks.  That sounds like it would fix this issue.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





CWilt@xxxxxxxxxxxx 
Sent by: security400-bounces@xxxxxxxxxxxx
05/27/2004 12:28 PM
Please respond to
Security Administration on the AS400 / iSeries  <security400@xxxxxxxxxxxx>


To
security400@xxxxxxxxxxxx
cc

Subject
RE: [Security400] object authority problem






Rob,

Just an FYI  but BPCS may have some updates to take care of the problem.

We're on an old version (4.0.0.5 CD), but SSA support just sent us two
"fixes" along with a readme document titled "Implementing Secured BPCS
Databases with BMRs 62812 and 66713 and Adopted Authority on the iSeries
Platform"

The readme document mentions the following about the command line:
"Note that various menu programs in BPCS CD contain a call to the IBM
program QUSCMDLN. This IBM program adopts the authority of the previous
program level when it runs. SYS500D also opens several files in BPCS, so
requires the *OWNER authority to remain. Therefore you must do 1 of 2 
things
in order to secure the command line from your users when they are inside
BPCS. You can change QUSCMDLN to Use Adopted Authority *NO. This is fast,
but upgrades will overwrite this change and you will have to remember to
change the program again. Or you can order BMR. Or, you can order BMR 
66713,
which contains a modification to all the menu programs to call a small 
BPCS
CL program that then calls QUSCMDLN. This small program (SYSCMDC) is given
the attributes of User Profile *USER and Use Adopted Authority *NO. Also,
check your own custom code for calls to either QUSCMDLN or QCMD from a
program that runs under *OWNER authority. If this is set up incorrectly,
users will still be able to access BPCS files without using BPCS programs 
to
do so, due to program adopting the previous programâs authority in the 
call
stack. Thorough testing of your set up prior to moving the changes into a
live environment will ensure you have properly changed all program
authorities in your environment. "


HTH,
Charles


> -----Original Message-----
> From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
> Sent: Thursday, May 27, 2004 1:03 PM
> To: Security Administration on the AS400 / iSeries
> Subject: Re: [Security400] object authority problem
> 
> 
> I know that a similar situation occurs in BPCS.  Some program 
> in between 
> BPCSMENU and the program that gives you the command line 
> adopts authority 
> and passes it on down the line.
> 
> Ed's check to see if this is the issue is right on.
> 
> You can look at all the programs in your call stack to see 
> which one is 
> the culprit (the one with USRPRF(*OWNER)).  And then the 
> other pass it on 
> down with USEADPAUT(*YES).  If you can figure this out then 
> you'll finally 
> know the difference between these two parameters.
> 
> Which then begs the question does that particular program owner need 
> access to STRSQL?  Or does it really need an owner with 
> *ALLOBJ?  That 
> might be easier (and safer) than attempting to modify your 
> ERP package to 
> stop the funky adoption.
> 
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> Ed Fishel <edfishel@xxxxxxxxxx> 
> Sent by: security400-bounces@xxxxxxxxxxxx
> 05/27/2004 08:09 AM
> Please respond to
> Security Administration on the AS400 / iSeries 
> <security400@xxxxxxxxxxxx>
> 
> 
> To
> Security Administration on the AS400 / iSeries 
> <security400@xxxxxxxxxxxx>
> cc
> 
> Subject
> Re: [Security400] object authority problem
> 
> 
> 
> 
> 
> 
> 
> John wrote on 05/27/2004 03:27:13 AM:
> 
> > I given object authority *public = exclude for the object 
> STRSQL. When a
> > user signon to as/400, the ERP application is loading 
> (initial program)
> and
> > the user is able to excute the cmd STRSQL. If he signoff 
> and go to main
> > menu, then it is not allowed. Can u tell me what is 
> happening. The user
> has
> > no special authority
> 
> It sounds to me like the ERP application, or something it uses, has a
> problem with adopted authority. That is, if the ERP application is
> displaying a command line that allows the user to run the 
> STRSQL command
> then it sounds like the adopted authority is being propagated to the
> command line.
> 
> To test this, I suggest that you ask the user to enter 
> DSPOBJAUT STRSQL
> *CMD on that command line. If *ADOPTED is listed in the User 
> column then
> the authority to the STRSQL command is coming from adopted 
> authority. If
> *GROUP is displayed, then the authority is coming from one or more of 
> their
> group profiles.
> 
> Ed Fishel,
> edfishel@xxxxxxxxxx
> 
> 
> 
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries 
> (Security400) 
> mailing list
> To post a message email: Security400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/security400.
> 
> 
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries 
> (Security400) mailing list
> To post a message email: Security400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/security400.
> 
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) 
mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.