Re: Read Only Access Profile

On 10-Jun-2014 07:07 -0500, Chella R wrote:

I have a requirement to create a read-only profile. So the
expectation is the profile which would be created, should not be
able to write/update/delete records from files in any library of
the application. They should only be able to read the records. Can
you please suggest how this could be achieved?

The OS is built with /resource security/ at the most basic levels within the OS; distinct access is provided to the /objects/ and to the /data/. The Operating System (OS) does not provide an attribute of a User Profile (*USRPRF) to establish that a credentialed\signed-on user can operate only as a Read-Only User Profile :-( because each resource is expected to be assigned appropriate authorities. However, some client-based [e.g. database, ¿JDBC and ODBC?] interfaces might provide a read-only connection capability; the client software then also has to prevent the user from overriding the restriction on a read-only setting.

If the stated /requirement/ is complete as written, and the terms "files", "libraries", and "records" refer only to database data, then the Database file [member] Open exit point can be used to provide a user-defined exit program to implement the noted security requirements.

<www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/xopendbf.htm>
_Open Database File Exit Program_
"The Open Database File exit program is called when a job is opening a database file. This exit is called in the job that is attempting to open the file. The exit program is passed a list of files referenced in the open request and the open options. The exit program may set a return code value to end the open request. When an open request is issued, the operating system calls the user-written exit program through the registration facility. ...
..."

I have tried few options like RVKOBJAUT command, but I can't use this
on all the objects of all the libraries.

The Grant Object Authority (GRTOBJAUT) and Revoke Object Authority (RVKOBJAUT) are entirely capable of processing all of the objects in any\all libraries. Thus the alluded inability, the "can't", is an innaccurate implication, because any user with the necessary authority "can" establish whatever are the desirable resource security. There are legitimate reasons to *choose not to* effect such changes, but the OS certainly allows that activity on /all/ of the objects; albeit, best to use the Authorization List (*AUTL) instead of assigning or revoking the "private authorities" directly on each object, to limit the storage requirements for the tracking of access rights.