IBM i Authority is a wonderful beast with many layers of complexity. Like a big red onion, peeling back these layers is simple to do, but sometimes causes some tears, or occasionally full on sobbing and weeping.
On the positive side, setting these layers of authority is pretty straightforward as long you stay focused and keep it simple.
On the negative side, these many onion layers can be daunting, more than a little confusing, and easy to royally screw up!
The system can be anywhere from ultra secure to the other (naughty) end of the spectrum commonly known as “wide open”.
Since, I regularly see *ALLOBJ defined as a user class in various IT departments, let’s look at User Classes first.
note: I am not going to use any swear words, but if you are using *ALLOBJ to bypass the IBM i System Authority settings then you are
F$^%#$%^$ nuts and leaving the box wide open.
All-object (*ALLOBJ) special authority lets the user access anything on the system. It overrides any private authority settings and gives the user carte-blanche to go poking around in any file, any library, any program, basically they can do anything with any data anywhere on the system. They can read, edit and delete stuff. Very dangerous – use with extreme caution.
*SECADM special authority
Security administrator (*SECADM) special authority lets you fiddle with user profiles. If you have *SECADM you can create, change, and delete user profiles. Elevating and de-elevating (is that even a word?) other user profiles with ease.
*JOBCTL special authority
The Job control (*JOBCTL) special authority allows a user to change the priority of jobs and of printing, end a job before it has finished, or delete output before it has printed. *JOBCTL special authority can also give a user access to confidential spooled output, if output queues are specified OPRCTL(*YES).
*SPLCTL special authority
Spool control (*SPLCTL) special authority allows the user to play with spool control functions. This includes browsing, changing, deleting, displaying, holding and releasing IBM i spooled files.
*SAVSYS special authority
Save system (*SAVSYS) special authority is fairly self evident. It lets the user save, restore, and free storage for all objects on the system, regardless of whether the user has object existence authority to the objects.
*SERVICE special authority
Service (*SERVICE) special authority grants access to STRSST (start system service tools). *SERVICE allows the user to debug a program with only *USE authority and to perform the display and alter service functions. It also allows the more pointy headed users to do things like trace functions.
*AUDIT special authority
Audit (*AUDIT) special authority gives the user the ability to view and change system auditing characteristics.
*IOSYSCFG special authority
System configuration (*IOSYSCFG) special authority gives the user the ability to change how the system is configured. Users with IOSYSCFG can add or remove communications configuration information, work with TCP/IP servers, and configure the integrated webserver – the ICS (internet connection server). Generally, commands for configuring communications require *IOSYSCFG special authority.
IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.
WordPress Jetpack Error “Server unable to connect with my site http 404”
Give AS400 users the ability to change user authority temporarily
An old AS400 Quiz willed with technical questions and plain old fashioned AS/400 brainteasers
How to get IBM i command line during runtime using System Request 3
Trump announces we need to start planning for the Y10K Software Crisis
Adopting Authority – Problems with SQL RPG Programs