*PUBLIC *CHANGE authority left on production libraries and files

What Happened

A large number of IBM i shops still run production libraries with *PUBLIC authority set to *CHANGE or higher, at the library level, the object level, or both. In almost every case this is a legacy default rather than a decision anyone made, which is why asking who approved it tends to produce blank looks.

The mechanism behind it is the QCRTAUT system value, which sets the default public authority applied to newly created objects. On plenty of systems it is still sitting at *CHANGE, so every object created inherits permissive public authority at the moment it is created. Nobody grants this access. The system hands it out quietly on your behalf, and it has been doing so for as long as the value has been set that way.

There are two layers to check and people routinely check only one. Library-level *PUBLIC governs access to the library, and each object inside carries its own *PUBLIC setting. A carefully restricted library full of permissive objects is common, and so is the reverse, so a clean answer at one layer tells you very little about the other.

It survives for the same reason excess authority survives: nothing breaks. A permissive setting produces no error and no complaint. Worse, tightening it is the single change most likely to break a working integration, so it gets deferred, and deferring it has no cost until the day it does.

Why It Matters

*PUBLIC *CHANGE means any profile without a more specific authority can update or delete data in that library. Not read it. Change it and delete it. That distinction is the whole finding.

What makes *PUBLIC more consequential than it looks is the order IBM i checks authority in. It looks at the user's own authority, then the authority of the groups the user belongs to, and then *PUBLIC. So *PUBLIC is the floor applied to everyone you did not explicitly handle, and on a real production system that is most profiles, including ones created after whoever designed the authority model left.

Put that together with the network routes most systems still leave open and it becomes the most common route to unauthorized data modification that assessments actually find. The user carefully restricted to three menu options can update the same file directly through ODBC, because the menu was never the control and *PUBLIC *CHANGE was.

This one also differs from the rest of the list in kind, not just degree. The other findings are mostly about data being read. This one is about data being changed, and silent modification is considerably harder to detect and to unwind than a copy being taken. You can often prove what was read. Proving what a wrong value used to be, months later, is a different exercise.

Recommended Actions

• Inventory *PUBLIC authority at both the library level and the object level, since a restricted library full of permissive objects is a common and easily missed combination
• Check QCRTAUT, because it sets the default public authority for newly created objects and is frequently still at *CHANGE
• Change QCRTAUT as well as the existing objects, otherwise tomorrow's objects arrive carrying the old default and you repeat the cleanup
• Move toward *PUBLIC *EXCLUDE, or *USE where read access is genuinely required, with explicit group-profile grants covering the access people actually need
• Use adopted authority in application programs rather than broad *PUBLIC grants, so the program carries the access instead of everyone on the system
• Run Authority Collection first to see which profiles actually exercise that access, so you tighten against evidence rather than against a guess
• Test in a non-production environment before enforcing. This is the change most likely to break an existing integration, and the breakage is usually a batch job nobody remembered
• Re-check after restores and migrations, because restored objects can bring their original authority settings with them and quietly undo the work

Sources

• IBM i object authority documentation
• IBM i system values reference (QCRTAUT)