RE: RE: Prevent User Profile from using public authority

Rob,

I would try to identify the common entry points for your application.
Those will usually be menu systems, batch routing programs and several
server exits. Those could adopt but adoption has all sorts of
limitations with things like IFS files and triggers and can often lead
to unintended exposures. I prefer to set effective group(s) for the user
at those authorized common entry points. If you use this technique, you
will also want to revoke authority with a registered exit or scope
message that does a profile swap. Using this technique, no one without
special authorities can do anything that *PUBLIC cannot do without going
through your designated entry points.  Those entry points need to be
very well thought out and secure. Assuming that someone can likely get
to a command line or equivalent somewhere, you may want to make sure
users are limited capability and review commands that are allowed for
those users.

It is a lot of work to secure your system and I don't think anyone hits
everything all of the time so journaling/auditing are important.

David Morris

>>> rob@xxxxxxxxx 04/26/05 9:04 AM >>>
It's still an open access method.  For a number of reasons.

In Patrick's article (always eloquent) he stated that most shops allow

people access to the data except the data they want to control.  That
is 
an open shop.  A closed shop would change system value QCRTAUT to
*EXCLUDE 
and then only let them access to data they wanted them to have.

Another thing that makes it an open system, in my mind, is that your 
method would still allow the users to UPDDTA, etc the files in
question. 
It would also allow them to ftp the data, etc.  Pat mentioned that you

could use exit points to restrict this, but ideally you would not let
them 
have access to the data, as a default, in the first place.

One method is to only allow access via programs that adopt authority.
This 
way the users have no direct access to the data itself.  We found that
our 
canned package has every program set to USEADPAUT(*YES).  All we would

have to do is to change the initial program to be owned by a user with

access to the data.  The only problem with this package is there are
too 
many points where the users are given a command line via CALL QCMD or 
QUSCMDLN and the thought of doing CHGPGM USEADPAUT(*NO) on these two 
hasn't been totally worked through yet.  This would effectively lock
out 
all access via other tools, interfaces, etc for these users.  And now
that 
the thought of changing QCMD and QUSCMDLN just hit me, it bears another

round of internal discussion.

Rob Berendt