[rt-devel] RT2 ACLs

Arthur de Jong arthur at West.NL
Wed Apr 4 07:45:09 EDT 2001

Since we (for the company I work for) need the correct implementation of ACLs 
in RT2 I spent some time to find out what the different rights in RT2 are, 
what they do and what they should do. The only two things that currently keep 
us back from switching to RT2 are the migration tool and the ACLs.

Current ACLs  (could be used as part of documentation)

Rights can be granted to users and groups to define what the user is allowed
to do and change in RT. Rights can apply to the whole of RT and all the
queues (global) or can apply to a single specific queue. Rights can be
granted to individual users and to defined groups of users.

Rights can also be assigned to pseudogroups that define users in a context.
The pseudogroups are "Everyone" (all the users on the system), "Requestor"
(users that are requestor in the context of the current ticket), "Cc" (users
that are Cc , either direct by the ticket or defined in the queue, of the
selected ticket) and "AdminCc" (users that are Administrative Cc to the

The effective rights of a user are the combination of the global personal
right, the combined global rights of the groups the user is in, the rights of
the user and all the groups that the user is in to the currently selected
queue and the rights the user gets through the pseudogroups.

A description of all the rights that users and groups can be assigned in RT

AdminGroups (global only)

  Users with this right are allowed to create new groups, modify the name and
  description of the group and add and remove registered users to and from
  the group.

  1-3-68: This seems to be implemented. A user without the AdminGroups right
          does however have the right to view all the groups on the system
          including who are members of the group.

AdminKeywordSelects (global and queue)

  Users with the AdminKeywordSelects should be able to add, delete and modify
  keyword selections for a specific queue (or all queues if this right is set

  1-3-68: Trying this as u user without AdminKeywordSelects causes a System
          error. All users have the right to browse the keywords (not a

AdminKeywords (global only)

  Users with the AdminKeywords rights can add, modify and delete keywords.
  Keywords are global to RT.

  1-3-68: Users without this right cannot change keywords (but receive not
          error). Users can browser all keywords.

AdminQueue (global and queue)

  Users with the AdminQueue right can change (all???) the queue settings. If
  the setting is global it applies to all the queues. These settings include
  basic settings like name, description, email addresses and priorities.

  1-3-68: seems to work

AdminUsers (global only)

  Users with this right are allowed to add and modify users.

  1-3-68: Users without the right to do so are presented with a "create a new
          user" link. All users are allowed to browse all the registered
          users. Non-privileged users cannot be listed.

CommentOnTicket (global and queue)

  Users with the CommentOnTicket right are allowed to add comments to
  tickets. When this right is global a user can add comments to all the
  tickets in RT otherwise the user is only allowed to comment on tickets in
  the specified queue.

  1-3-68: any user can add comments to a ticket (not implemented)

CreateTicket (global and queue)

  Users with the CreateTicket right can create requests in the specified
  queue or in all the queues if global is selected.

  1-3-68: working in all the right places I could find

DeleteTicket (global and queue)

  A user with the DeleteTicket is allowed to set the status to "dead"????

  1-3-68: not implemented, is this used? The status selector of a ticket
          shows dead (Modify.html) even if the user does not have the
          DeleteTicket right.

ModifyACL (global and queue)

  If a user has the ModifyACL right he/she can change the rights different
  users and groups can be assigned regarding queues. If the ModifyACL right
  was granted globally the user can change all the ACLs in RT, including the
  global ones (including granting him/herself SuperUser privileges).
  ModifyACL does strange things without ShowACL.

  1-3-68: When you try to remove a single given from a single group right and
          the user is not privileged to do so a number of error messages is
          generated (equal to the number of registered groups) (potential

ModifyQueueWatchers (global and queue)

  This rights enables a user to register and remove other users as watchers
  (cc and admin.cc) to a queue. If this right is assigned globally the user
  can modify watcher settings of all the queues.

  1-3-68: This does not seem to be implemented as any user is allowed to
          change the watchers to a queue.

ModifyScrips (global and queue)

  This right allows a user to add and delete scrips from a queue of, if the
  right is granted globally, change the global default scrips.

  1-3-68: Wrong without ShowTemplate. Deleting a scrip by an user without the
          ModifyScrips right results in a "Scrip deleted" message without
          deleting the scrip.

ModifySelf (global only)

 This allows the user to change his/her personal settings.

 1-3-68: The user is allowed to change his/her unix login username and
         enable/disable privileged user setting. When displaying a user and
         changing the privilege status the status does not change in the user
         settings but does change in the page (strange). Should this right be
         granted to everyone and should this affect the Preferences page.

ModifyTemplate (global and queue)

  The user is allowed to modify the templates. If this right is granted
  globally the user may modify the global templates and the templates for all
  the queues.

ModifyTicket (global and queue)

  The user is allowed to modify the ticket. Modifying the ticket includes
  changing the subject, status (except dead???), time worked, time left,
  priorities, queue the ticket is in (only queues the user has rights
  to????), ticket dates, keyword values, owner (to users that are allowed to
  own the ticket?), requestor and watchers and relationships with other

OwnTicket (global and queue)

  Only users that have the OwnTicket right can be owners of a ticket. This
  right can be granted globally or per queue.

ReplyToTicket (global and queue)

  User with a ReplyToTicket right can add replies to a ticket.

  1-3-68: The selector in the comment ticket page (and jumbo) does not
          reflect the granted permissions. There are links to comment (and
          others) even if the user does not have the right to do these.

SeeQueue (global and queue)

  This allows users to see what tickets are in the specified queue and to
  search the tickets in the queue. If this right is granted globally the user
  is allowed to search and display all the queues.

  1-3-68: All users are allowed to see what queues there are through the
          Administration->Queues link. With the search link any queue can be

ShowACL (global and queue)

  This allows the user to view the currently active ACLs (rights granted to
  users and groups). When this rights is applies globally the user is allowed
  to view the ACLs of all the 

  1-3-68: All the users seem to be able to view all the queue ACLs.

ShowScrips (global and queue)

  Users with this right are allowed to view the scrips.

  1-3-68: Global scrips are not shown but a checkbox is displayed.

ShowTemplate (global and queue)

  Users with this right are allowed to view the mail templates.

ShowTicket (global and queue)

  Users with this right are allowed to display the ticket.

ShowTicketComments (global and queue)

  Users are allowed to view the comments entered with tickets.

SuperUser (global only)

  A SuperUser is allowed to do anything.

Watch (global and queue)

  A user is allowed to be registered as watcher?

WatchAsAdminCc (global and queue)

  A user is allowed to be registered as administrative watcher?


RT2 has a lot of different rights that can be granted to users what makes it
very flexible but also may makes RT difficult to manage. The currently
available rights and permissions are not ideal.

I suggest trying to loose sine of these rights to simplify the implementation
and maintainability.  Another thing would be to increase consistency in
naming to use Admin* rights for administrative tasks and Modify* rights for
general operational tasks. Maybe something like:

AdminGroups (only global)
AdminKeywords (only global)
AdminUsers (only global)
AdminQueue (with AdminKeywordSelects, basics, watchers, scrips, templates and
            keyword selections)
AdminQueueACLs (was ModifyACL, applies to user and group ACLs in queues,
                implies ShowACL)
ModifySelf (should only apply to passwd, signature and maybe a few other

If AdminQueue and AdminQueueACLs are applied globally they would apply to all
the queues and the default settings. Alternatively AdminQueue could be split
in AdminQueueBasics, AdminQueueWatchers, AdminQueueScrips,
AdminQueueTemplates and AdminQueueKeywordSelects.

This would imply getting rid of AdminKeywordSelects (would be in AdminQueue),
ShowACL (no practical need, in AdminACL), SuperUser (can be easily combined
from all other rights) ModifyQueueWatchers (in AdminQueue) ModifyScrips (in
AdminQueue), ShowScrips (in AdminQueue), ShowTemplate (in AdminQueue),
ModifyTemplate (in AdminQueue).

This way user with any Admin* rights would have access to the administration
part of RT and others would not. The other rights:

SeeQueue (see the tickets in the queue, ShowQueue?)
CreateTicket (allow to create ticket in queue)
ShowTicket (view the ticket basics, replies and status)
ShowTicketComments (also show comments in ticket)
CommentOnTicket (allow adding comments)
ReplyToTicket (allow sending replies)
ModifyTicket (allow changing basics, keywords, relationships, dates and
              watchers was ModifyTicket)
OwnTicket (allow to be owner of ticket)
Watch (allow to be added as watcher)
WatchAsAdminCc (allow to be added as adminwatcher)

The user interface should better reflect the rights of the authenticated
user. The user should only be presented with the means to change information
is the user is allowed to do so.

It might be a good idea to have a page to view all the rights a user has,
including how he got them (by groups etc). This is not easy and context
dependant since some rights can be granted through the pseudogroups (cc,
owner, admin cc).

Sorry if this long story is somewhat incoherent but that's this is the result
for the amount of time I can spend on it. We really need better ACLs.

-- arthur de jong - arthur at west.nl - west consulting b.v. --

More information about the Rt-devel mailing list