Types of permission

In InfoPrint Manager, users can have three levels of permission: read, write, and delete. The levels provide these types of access.

  • Read- For operations, the user can perform the operation. For servers and queues, the user can view the attributes. For destinations, the user can view attributes and submit jobs to that destination.
  • Write- For all objects, the user can modify attributes.
  • Delete- For all objects, the user can delete the object.
    Note: The levels of permission are not cumulative. If you give a user delete permission only, he will not automatically have read and write permissions. Be sure to mark all of the levels of permission that the user needs.

If you place user A on the ACL for the logical destination "print2ld" and give her read permission, she can send her print jobs to it and can open the “print2ld” object to see its properties. However, she cannot make changes to those properties. If she tried to change any of them or tried to delete the destination, she would receive an error message. If you decide that user A needs to be able to do more and give her write permission as well, she will be able to change the properties of “print2ld,” but still will not be able to delete it.

Important: If you protect a destination (logical or actual) so that only certain users can modify or delete its properties, you might inadvertently prevent other users from submitting print jobs to it. To be sure that all of your users can still print to the destination, add the wildcard character (*) to the ACL as a user with read permission.

You can also attach ACLs to the operations that you can perform on InfoPrint objects. Allowing you to protect both operations and objects means that InfoPrint Manager Security provides different levels of security: you can protect all objects by using ACLs at the operation level or you can protect individual objects with ACLs applied only to them. Or you can do both: protect all objects by using operation-level ACLs for some operations, and limit access to subsets of objects by using object-level ACLs.

For operations, there is only one level of permission: read. If a user has read permission, he can perform that action; if he does not, he cannot perform the action. For example, user B is a printer operator and must be able to move jobs to different positions in the print queue because some jobs need to be printed before others. You can give user B read permission for the operation Reorder Job to allow him to do his job. On the other hand, user C submits print jobs from his office workstation and does not like to wait for the jobs ahead of his in the queue to print. To prevent him from moving jobs, do not put him on the ACL for the Reorder Job operation. When he tries to move his job to the top of the queue, the action will be denied.

When you install InfoPrint Manager, many operations are already protected so that only members of the admin and oper groups can perform them. You can see the ACLs for operations in the Management Console by selecting the Security-ACL-Operations item in the left pane. If you want users to be able to perform those operations, you must either add those users to the individual ACLs or to a group that has permission (either the existing admin and oper groups or a new group that you create).

Note: If an object is protected, a user can only perform an operation on that object if he has both read permission for the operation and the appropriate level of permission for the object (for example, a job or a printer).
  • If the object is not protected, any user with read permission on an operation can perform that operation.
  • If the object is protected, the permission needed depends on the operation. For example: List requires read permission on the object, Set requires write permission, and Delete requires delete permission.

By default, InfoPrint objects (destinations, queues, servers) are not protected, members of the admin group have read permission on all operations, members of the oper group have read permission on most operations, and all users have read permission on five operations. Those five operations are:

  • List/Query (all objects)
  • Print
  • Modify job
  • Query job
  • Remove job (delete job)
However, users who are not members of the admin and oper groups can only modify and remove jobs that they submitted. In addition, if the ACL for the Reorder job action is changed so that everyone can use it, users who are not members of the admin and oper groups will only be able to reorder jobs that they submitted. By default, members of the admin and oper groups can do all six of those operations on all jobs.
Note: If you decide to protect your queues, all users will still be able to perform the tasks listed above on their own jobs. Users who are on the ACL for a queue will be able to perform those tasks on all jobs in that queue.