Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Spool File Security

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

  • Spool File Security

    What release is your machine running? Why did you decide to give some users *SPLCTL authority as a method to authorize them to reply to messages for spool printer writers? Did this allow them to reply to messages that they were not allowed to reply to when they did not have *SPLCTL special authority? Without knowing more, the only thing I can think of that would cause this behavior is if your system were using a reply handling exit program registered to the QIBM_QMH_REPLY_INQ exit point in the registration facility. Please use WRKREGINF to determine if you have an exit programs registered at this exit point. Let us know what you find there. I wrote an article on this exit point and provided the source for a sample exit program. See http://www.eservercomputing.com/iser...=12&id=769&p=1 for more information. If your system just happens to be using this sample exit program then a better solution (than giving users *SPLCTL) might be to change the exit program to add an authority check to some object (such as a specific data area) after the program does the check for *SPLCTL. Then you could authorize a set of users to reply to any print writer message by granting them private authority to the data area. If you are not using this sample exit program then do not start using it until you first understand why giving your users *SPLCTL allowed them to reply to messages. I hope this helps. Ed Fishel

  • #2
    Spool File Security

    Thx for the advice Ed - I was able to solve my problem by giving the users in question *JOBCTL instead of *SPLCTL DF

    Comment


    • #3
      Spool File Security

      Dave, Giving users *JOBCTL instead of giving them *SPLCTL may not be any safer. It is true that you can keep a person with *JOBCTL special authority from viewing spooled files. Unfortunately the users that you gave *JOBCTL can now change, hold, and end jobs that belong to any other user. They can also start and end subsystems. Ed Fishel

      Comment


      • #4
        Spool File Security

        I am trying to accomplish the following: I want my users to be able to only view their spool files & nobody else's and in some cases be able to answer messages on certain printers/output queues. When I use the OPRCTL(*NO) & AUTCHK(*OWNER) options on the CHQOUTQ command I can accomplish the first part of my goal. When I add special authority *SPLCTL on the users that I want to have the ability to answer printer messages - they then also now have the ability to view all spool files. Any ideas on how to do both ?? thx DF

        Comment


        • #5
          Spool File Security

          In order to answer the messages for a printer the user needs to have authority to the message queue. The easiest way to handle this is to create a message queue for the printer (same name as the printer is easiest), change the device description of the printer to point to this message queue and make sure the users have authority. This has the added advantage of seperating the messages for different printers.

          Comment

          Working...
          X