Make sure the user profile you create does not have *ALLOBJ special authority. A user with *ALLOBJ cannot be prevented from updating or deleting objects.
If you put the user profile in a group or groups, make sure the groups don't have *ALLOBJ special authority. Some people try limiting what a user can access by assigning *ALLOBJ special authority at the group level and excluding the user from various objects or functions. While on the surface this may seem like a viable option because the user's authorities will be checked by the i5/OS authority checking algorithm before the groups', there are many ways to circumvent this exclusion. For example, all a user has to do is submit a job to run under a profile that has sufficient authority to access the object or perform the task for which he has been excluded. (Because the profile's group has *ALLOBJ, he has sufficient authority to specify any profile on the Submit Job (SBMJOB) command.)
Make sure the system is running at security level 40 or 50 (QSECURITY = 40 or 50). Several ways exist to by-pass security at lower security levels, including submitting a job using a job description that names a powerful profile. At security level 30 and below, a user only needs authority to the job description but not the profile specified in the job description. At security level 40 and above, using the job description requires authority to both.
Identity the applications for which the user needs access. For all other applications, exclude the user from the libraries and directories which comprise these applications. (In other words, grant the user *EXCLUDE authority.) For very sensitive applications such as HR or Payroll, you may want to set the *PUBLIC authority of the libraries and directories to *EXCLUDE after identifying and accommodating the users and processes that need access. If there is more than one user for which you want to configure to be "read-only" (and, most likely, there is), then exclude the users' group from the libraries and directories, to simplify administration.
Identify the access control policy for the objects – and especially the files – in the applications for which the user needs access. Meaning, what authority does this user need to the data in this application when accessing the data outside of the scope of the application – such as through a command line. In the "read-only" case, the data access policy is that users should be able to read or download the data, but not modify the data outside of the application. This implies that the *PUBLIC authority on these objects – specially the application files - should be *USE. Note: Before blindly setting application files to be *PUBLIC *USE you will have to ensure that the application interfaces provide sufficient authority so that the application will still work. My favorite technique is for the application to adopt authority. The adopted authority provides sufficient authority to modify the data coming through application interfaces. However, when accessing the data without using application interfaces, the adopted authority is not in affect.
Creating a "read-only" profile is not impossible. But it does take some investigation and planning to achieve the objective of allowing the user to read, but not update, the data and not break anything in the process.
is co-founder of SkyView Partners Inc, a firm specializing in policy and compliance management software, including SkyView's newest product, Policy Minder for OS/400 and i5/OS, as well as security consulting and remediation services. Carol has over 15 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol's second book, Experts' Guide to OS/400 and i5/OS Security, is available at Amazon.com