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.
_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.