Read only user on AS400

No limited user should ever have *ALLOBJ or *SECADM.

*ALLOBJ gives the user access (read and write) to all objects on the system. *SECADM give the user access (read and write) to all security objects on the system. Because there are many ways to manage security on IBM i, you will need to develop a comprehensive security plan. I fear that this is not something that can be dealt with in a simple Q&A fashion. In fact you probably should contract with an IBM i security expert to get this done.

At a minimum (and probably maximum) the new user profile must have *USE authority to every user profile that you want it to view.

*ALLOBJ is the single most valuable and extensive authority on the system.  It is the approximate equivalent of a Domain Admin on Windows, or a root user on Unix.  You should only grant *ALLOBJ with extreme care, and only to your most senior system admins who absolutely need it to perform their job functions.  In many shops, logging on with *ALLOBJ to production systems requires special procedures due to the risk posed by this special authority.  In addition to unlimited access to every object in the system, once you have granted *ALLOBJ a user can use a variety of techniques to escalate their authority and gain access to all other special authorities, including sensitive special authorities like *SECADM, *SERVICE, *JOBCTL, *SPLCTL, and *IOSYSCFG.

DO NOT GRANT *USE RIGHTS TO USER PROFILES!

*USE authority (Object Operational + Data Execute authorities) allows the user to perform operations on behalf of the user profile that they have *USE rights to.  For example, if I have *USE rights to your profile I can submit jobs on your behalf, or even "become" you (and get all of your authorities) using the QSYGETPH and QWTSETP Swap User Profile APIs.
 
Perhaps if you would explain why you want to have a user with read-only access to user profiles, we could provide more specific advice.

Gary is correct, you have to be very careful in granting any access to user profiles. We need to know more.

Excellent advice so far. *ALLOBJ is not to be messed with. A user with *ALLOBJ can obtain any other desired authority (with a little knowledge, and the Internet can provide knowledge).

Perhaps the simplest is just to create a program that adopts sufficient authority, then grant *USE authority for that program to your limited user. The user can then only do the specific tasks that the program allows and can do it only when actually running that program.

Can you give the user *SECADM and *SYSOPR and a menu with no commandline?

USER info can be retrieved by SQL

SELECT * FROM QSYS2/USER_INFO as INFO

No, it is a very bad idea to give general users *SECADM and *SYSOPR. It opens up way to much. 5250 is not the only way to get onto IBM i today, so you can't restrict a user to the menu system.

If a program runs as *SECADM+*SYSOPR, it can run the SQL. The user then only needs *USE authority to that program. Adopted authority can help with a lot of basic security concerns. If the system is older so that the SQL isn't effective, the alternatives can load data.

Perhaps ideally, the adopted authority program would run only as a submitted job. It would load a table to which the user has *USE authority. That separates user from authority, but provides desired info.

There is an option to Limit Capabilities of User During Creation of User ID. You can use that and grant authorities to read only commands like DSP*.
Alternatively, after Creating User ID , revoke all the Command Access for that Profile (Using RVKOBJAUT) and then Provide the access to those 3 or 4 commands that are required by the user to look into system.

Care must be taken with Limit Capabilities. Every command that might be risky (and there are many) must be examined to see if each one honors the attribute. Commands can be changed. Also, not all interfaces honor the attribute; it applies primarily only to system command lines. And similar concerns apply to RVKOBJAUT since there are thousands of commands. It can take a long time.

Then, monitoring of changes to commands should be set up since any command might be changed at any time.

Definitely remove *ALLOBJ. If for certain functions this is needed then you can call a program that either ADOPTS the necessary authorities, or alternatively uses 2 APIs ('QSYGETPH', and 'QSYGETPH') to temporarily actually become a different user.

@P_S_Price3:  Think you meant to say QSYGETPH and QWTSETP.

Certainly  did.

We've given a lot of guidance in this thread on what NOT to do.  Now let's talk about how to properly secure a system.  THis is a very high-level overview, but the basic process for configuring resource security is:

1) Determine object access requirements by job role.
2) Create group user profiles that align to job roles.  Users can be a member of multiple groups.
3) Create authorization lists for related objects in the system.
4) Assign objects to appropriate authorization lists.
5) Assign groups appropriate rights to objects via authorization lists.
6) Revoke public authority to objects.
7) Restrict assignment of *ALLOBJ, which bypasses all of the restrictions above.

So, for the example of user profiles:

1) Create an authorization list called "USRPRF" with *PUBLIC *EXCLUDE
2) Create a group profile called "USRVIEW", and make users you need to view all profiles members of this group.
3) Add the group USRVIEW to the USRPRF authorization list with *USE (or whatever rights you choose)
4) Change all end-user user profile objects to use the authorization list, and revoke *PUBLIC authorities (GRTOBJAUT).
5) Remove *ALLOBJ from the users in the USRVIEW group.

Strongly suggest creating in a test environment, or with test profiles before deploying in a production environment.

Note: you need to use caution (or simply avoid) changing authority on system-supplied user profiles.  Refer to the IBM I Security Reference for more information on system-supplied profiles.

In general, you should familiarize yourself thoroughly with IBM i security documentation, attend a security class, and/or get assistance from an in-house or outside IBM i security expert before making large-scale or complex changes.