Robot – Change object security of fle REPPF in RBTREPLIB library
Application development, AS/400, Development, Printing, RPG, RPGLE, Security, Software, Tech support
I am planning to read file REPPF from RBTREPLIB library from a program. The security of this object is setup as the following:
User Object Authority
*PUBLIC *EXCLUDE
RBTUSER *ALL
Because the way the security is setup, the program only will work for those users that complies with this security.
Can I change the object authority of the user *public to *USE? Will that change affect the way Robot works?
Software/Hardware used:
Software/Hardware used:
ASKED:
March 8, 2006 2:27 PM
UPDATED:
December 1, 2009 7:10 AM
Answer Wiki:
What is the opinion of your robot reseller ?
To see all answers submitted to the Answer Wiki: View Answer History.
It should not change the way Robot works, as Robot access is via the RBTUSER profile. It will allow users who fall through to the *PUBLIC security check to be able to use the file. I am not sure what is contained in this file, you will have to review the contents and determine the risks of the public being able to use the file.
Only the vendor knows for _certain_ whether an authority change will matter. For example, the app could explicitly retrieve the authority from the object and use the returned values to control other processes. This is unlikely, IMO, because that technique would usually use an *AUTL to store the values rather than an object that is in use. But you never know.
Personally, I wouldn’t change a 3rd-party apps authority values unless it’s a normal, documented procedure. That means you would find a section in the Administrators Guide or Users Guide that described how and why it would be done.
Instead, I would compile my program with CRTPGM USRPRF(*OWNER) and have it owned by a profile that has sufficient authority such as the *ALLOBJ special authority. (Not QSECOFR nor any other IBM profile, but a profile created with password *NONE and used for this kind of purpose.) You would then give users *USE rights to the program. Not *PUBLIC which should be *EXCLUDE just like the Robot file, but only the users who are allowed.
There might only be a single user given the authority to call the program. And that user might be a group profile so you can add (and remove) other users to the group as needed. The *OWNER should not be one of the authorized users of the program.
The best thing to do is compile your program with a user id that has *allobj authority (like qsecofr) and have it adopt owner authority. Or add your programming group i.d. as *read authority to the object and, again, compile with adopt owner authority.
In any case, altering the contents of the file in any way, or holding a lock in the file or contents may trigger a problem in robot with serious repercussions.
How about this: copy the file to qtemp, then process that one – then you’re certain not to mess up or block robot.
Do not alter the authority on the file. Period. Don’t go adding users to it such as your “programming group”. Any distributed fix for the product or an upgrade can wipe out your change and cause an unpredictable failure of whatever procedure you’re creating. Further, changing a 3rd-party product puts your support agreement in jeopardy.
Tom