Profiles, authorities and security levels

A user, here, is an object: a user profile, type *USRPRF, living in QSYS like everything else. It holds the password, the authorities, the job description its work takes settings from, the current library, the initial program.

There is no separate list for the database, one for the operating system and one for the application: whoever connects over SQL from a PC and whoever signs on to a 5250 session are the same profile, with the same authorities. That is a considerable simplification compared with other platforms, and it has a consequence not everyone accounts for: a profile designed for the green-screen application carries the same authorities into an ODBC connection, where the menus that constrained it are no longer there.

Special authorities

Eight authorities override normal object checking. These are they, and they are worth knowing by heart:

*ALLOBJ is the front door key. *SAVSYS and *SPLCTL are nearly as much and go unnoticed: whoever can save can carry everything away, whoever sees all printed output sees the payroll.

Who has them:

SELECT AUTHORIZATION_NAME, STATUS, SPECIAL_AUTHORITIES, TEXT_DESCRIPTION
  FROM QSYS2.USER_INFO
 WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'

Object authorities

Beneath special authorities sits normal checking, which comes in two forms. Commands use four summary levels:

• *EXCLUDE — no access;
• *USE — read and run;
• *CHANGE — read and change the data;
• *ALL — everything, including deleting the object and changing its authorities.

Beneath the four levels are the real authorities, split between object (*OBJOPR, *OBJMGT, *OBJEXIST, *OBJALTER, *OBJREF) and data (*READ, *ADD, *UPD, *DLT, *EXECUTE). Day to day you work with the four; the ten matter when exactly one thing has to be granted — reading without being able to delete the object, say.

Every object also has a public authority, *PUBLIC, applying to anyone not otherwise provided for. What new objects get is decided by the system value QCRTAUT, and in the factory configuration that is *CHANGE.

Groups and authorization lists

Authorities granted profile by profile become unmanageable within a year. Two things make them governable:

Group profiles. A profile can have one primary group and up to fifteen supplemental groups; authorities are granted to the group and members inherit them. A group, here, is an ordinary user profile used as one — there is no separate object type.

Authorization lists (*AUTL). A list holds who may do what, and objects are told to follow the list. Changing the list changes the authorities of every object following it at once, even thousands. It is the right tool when many objects must share the same rules, and it is also the only way to grant authority to an object while it is in use.

CRTAUTL AUTL(PAYDATA) TEXT('Payroll files')
ADDAUTLE AUTL(PAYDATA) USER(GRPPAY) AUT(*CHANGE)
GRTOBJAUT OBJ(PRODLIB/PAYROLL) OBJTYPE(*FILE) AUTL(PAYDATA)

Adopted authority

A program can run with the owner's authority instead of the caller's: CRTxxxPGM ... USRPRF(*OWNER). This is the mechanism that lets the application update files the user alone could not reach — and therefore lets users be kept at low authority without giving anything up.

Security levels

The system value QSECURITY decides how seriously the system takes all this:

• 20 — password required, but object checking is not enforced as it should be, and profiles are created with very broad authority. To be considered unacceptable today.
• 30 — password plus full object checking. The sensible minimum.
• 40 — as 30, plus integrity protection: programs cannot use unsupported interfaces to step around the system. It is the default on new systems and the level to aim for.
• 50 — hardened integrity, for environments with formal compliance requirements.

DSPSYSVAL SYSVAL(QSECURITY)

Where to start on an inherited system

Four questions, each answered by one query or command:

1. How many profiles have *ALLOBJ, and who are they really?
2. Are there enabled profiles that have not signed on for months? They almost always belong to people who no longer work there.
3. What is QSECURITY set to?
4. Is auditing on — QAUDCTL other than *NONE — or is the system recording nothing of what happens?