Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Program Security Level

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Program Security Level

    Don, I would start by restricting the command line and setting your users' profiles to limit capabilities *YES. This is pretty simple. The hard part is if you have users who are used to executing system commands. If you are talking about an inhouse developed program, you can change the security of that program object using WRKOBJ. The work with object will allow you to set security for that one object. In lieu of my first suggestion, you can change the object to public(*EXCLUDE) and the give user_name(*USE) for those who need access to it. Again, you have to have users who don't have *ALLOBJ authority, or who can't use the CALL cmd from a command line area.[*]*** Remember **** Give your operator(s) at least *CHG authority so they can save/restore/delete the object in question, but especially the save. If this is for an IBM supplied command, you will have to be more specific about which one and what/who you want to lock out of it. -bret

  • #2
    Program Security Level

    What is a simple way to protect the execution of a program to only a special few people? I'm a little overwhelmed by security. Thank you. Don

    Comment


    • #3
      Program Security Level

      Brett, With all due respect, your reply contains a number of inaccuracies.... In order to execute a program, the user must have at least *USE authority to the program. A user can get *USE either from their own profile, or from one of their group profiles, or from having the *ALLOBJ special authority. They can also get *USE authority by adopting the authority of a user that has *USE authority. *USE authority to a program is sufficient to run a program. If the program reads files, the user must have *USE authority to the underlying files. If a program changes data in files, the user must have *CHANGE authority to the underlying files, etc. Giving a user limited capabilities may inhibit, but will not prevent that user from entering commands or executing programs. Client Access and DDM both provide remote command capability that does not pay homage to the LMTCPB(*YES) parameter in the user profile. Please do not rely on LMTCPB alone to restict access to commands and programs. Also, Operators who have *SAVRST special authority will be able to save and restore objects that they do not have direct authority to. There is no need to give your operators *CHANGE access to production objects in order to allow them to save and restore. This is the purpose of the *SAVRST special authority. Further, *CHANGE authority will not give anyone the right to delete an object. You must have *OBJEXST (object existance) authority to delete objects. I would not reccommend that system operators have this ability. jte

      Comment

      Working...
      X