RE: MAPICS Object/File Security...

["Shaw, David" <dshaw@xxxxxxxxxxx>]

Steve,

My first observation is that the authority settings in your MAPICS
installation have been modified fairly radically from the way that the
package installs.  Let me describe a vanilla installation:

1) Nearly all objects (programs, commands, and especially ALL database
files) have *PUBLIC authority set to *EXCLUDE.
2) Most programs adopt AMAPICS authority, except for a handful that adopt
QSECOFR and another handful that don't adopt at all and have the use adopted
authority setting set to *NO.  (I don't specifically remember any owned by
or adopting QPGMR, but there may be a few - I'd ask MAPICS support about
that).
3) The AMAPICS profile is also *PUBLIC *EXCLUDE and is NOT used as a group
profile.

Typically the kinds of changes you describe are the result of:
1) The *PUBLIC *EXCLUDE on the database being too restrictive.
2) Someone having an irrational fear of programs adopting authority, either
because they think it "hurts performance" or it's a "dangerous security
practice".  Of course then they give *PUBLIC *CHANGE and/or put all the
users into a group under AMAPICS, both of which are far more dangerous.

My opinion on what you should do:
1) Put the programs back to the vanilla adoption scheme.
2) Get AMAPICS off those user profiles.
3) Make sure that *PUBLIC has no more than *USE for any MAPICS file,
program, etc - and *EXCLUDE for sensitive items, like most of the Payroll
objects if you have Payroll and are using it.
4) If specific users need more authority than allowed in point 3, grant it
to them specifically.  I prefer to assign groups of objects to a common
authorization list, and then grant the individual authorities in the
authorization lists.  Much simpler to administer, since you don't need to
allocate the objects exclusively to change user authorizations, and changes
to all the objects in the group using a particular list have changes taking
effect simultaneously.

This will give you a setup similar to what I established at my previous
employer.  It worked well there for the 9 years I was there after
implementing it, and I understand it's still working pretty well for them.
One day I hope to get our INTEX installation here set up in a similar manner
- right now it's a disaster waiting to happen at the most inconvenient time.

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

> -----Original Message-----
> From: stephen.hunt@legrand.co.uk [mailto:stephen.hunt@legrand.co.uk]
> 
> I've been given the task of tightening up our MAPICS object 
> and file security
> (someone else looks after the user security within MAPICS).  
> Were currently on
> XA v2r3, but will soon be migrating to v2r4 (once all our 
> add-on modifications
> have been upgraded/tested).
> 
> All our MAPICS libraries, objects and files are now owned by 
> user AMAPICS
> (previously some were owned by QPGMR and QSECOFR - and some 
> even adopted owner
> authority !!!).  All the MAPICS libraries, objects, and files 
> have PUBLIC
> *CHANGE authority.
> 
> Most MAPICS users have special authority *NONE and group 
> profile AMAPICS -
> although no one has OWNER(*GRPPRF) !!
> 
> As I currently know very little about MAPICS, I was hoping 
> that somebody could
> give me some pointers, suggestions, hints/tips, etc..
+---
| This is the MAPICS Mailing List!
| To submit a new message, send your mail to MAPICS-L@midrange.com.
| To subscribe to this list send email to MAPICS-L-SUB@midrange.com.
| To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dshaw@spartan.com
+---