RT2 ACLs


#1

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
ticket).

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
follows:

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
globally).

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
problem).

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
bug?).

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
tickets.

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
searched.

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?

CONCLUSION

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
things)

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@west.nl - west consulting b.v. –


#2

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.

Wow! I really appreciate the work that went into this. I’m interspersing
clarifications and notes. When I get a chance, I’m going to incorporate
this into the documentation.

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
ticket).
^ or the current queue

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
follows:

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.

Note that it is only privileged users. Folks who are set up as “requestors
only” can’t. It’s going to stay this way until at least 2.0.

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
globally).

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
problem).

Yikes! this is fixed in 1.3.70 (What will now become beta 2). Additionally,
the error message for trying to create or delete a keyword select without
permission is fixed.

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.

Browsing keywords will not be changed for 2.0. The Error message will make
it in for beta 3. It’s ticket #352

AdminQueue (global and queue)

Users with the AdminQueue right can change (all???) the queue settings. If

They can change anything on the queue ‘basics’ screen.
They can create queues (if granted the right globally)
They can “disable” a queue. Which means that no new tickets can be created
in the queue. In 2.2, what happens with stuff left in disabled queues will
be improved.

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.

Should be fixed for beta 3. it’s ticket #353

All users are allowed to browse all the registered users.

All privileged users. which is an important distinction. privileged users
are internal users who can be granted rights. Requestors can’t go browsing.

Non-privileged users cannot be listed.

Yes they can. they’re just not listed in the “default” listing.
Try the search box at the bottom of the listing.
UI for this will be improved in 2.2.

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)

Not true. Users with “ModifyTicket” can comment on and correspond on tickets

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.

Correct. this is “not yet implemented” I should probably yank it for beta3.

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
bug?).

Indeed. Ticket #354. Targeted at Beta 3.

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.

I beg to differ. it seems to work just fine here.

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.

nod It will continue to be only semi-functional without “ShowTemplate”

Deleting a scrip by an user without the
ModifyScrips right results in a “Scrip deleted” message without
deleting the scrip.

Ticket #355. Beta 3

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.

Yikes! This is no good. I just implemented a fix for ‘privileged’ fields
in User.pm.

The following fields are now only modifiable by folks with "AdminUsers"
permission:

Organization, Disabled, Privileged, Name, ExternalContactInfoId,
ContactInfoSystem, ExternalAuthId, AuthSystem, Gecos

The basic philosophy behind the decision about what to limit editing to
is that the user should be free to modify their own contact
info, but should not be able to modify RT username or fields that could effect
ACLs. (Organization is something that folks may be keying external lookups off. I could probably be convinced to make this ‘open’)

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).

Beta 3. Ticket #356 :slight_smile:

Should this right be granted to everyone and should this affect the
Preferences page.

It definitely affects the preference page. I’m wondering if we want
to code in the right for non-privileged users to: “SetPassword” and “SetEmail”

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,

Including dead for now

priorities, queue the ticket is in (only queues the user has rights
to???),

The user doing the transfer needs to have “CreateTicket” in the new queue
to create a ticket in that queue.

ticket dates, keyword values, owner (to users that are allowed to
own the ticket?), requestor and watchers and relationships with other
tickets.

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.

Good catch. #357 - Beta 3

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
searched.

#358 / Beta3. I need to think a bit more about this one, but it should be fixed
for beta 3

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.

#359 / Beta3

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.

#360 / Beta 3

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?

The user is allowed to sign up to “watch” this queue or tickets in this queue
as a cc or a requestor. The user is also allowed to stop watching tickets
in this queue. Think of this as AdminWatchers, but only for oneself as
requestor or CC.

WatchAsAdminCc (global and queue)

A user is allowed to be registered as administrative watcher?

Like Watch, but only as an AdminCc.

CONCLUSION

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.

One way to manage rights more easily is to create groups for ‘bundles’ of
rights that you frequently grant users as a single package. At this point
in the development cycle, the ACL setup for RT 2.0 is not going to change
signficantly. Further down the line, perhaps in the 2.4 timeframe, I’ll
definitely look at your recommendations as I start to design the next
rev of the ACL system.

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.

Indeed! I appreciate all the work you’ve done to note places where this isn’t
true at this point. I’m excited to get all this cleaned up when I get back from
my trip.

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).

A page to browse user rights will either come in a 2.0.x point release
or early in the 2.2 cycle. it would certainly be quite useful.

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.

It was quite well put together. Thanks!

We really need better ACLs.

I certainly hope the changes that I indicated meet your requirements.

– arthur de jong - arthur@west.nl - west consulting b.v. –


Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

And I’m told we do share some common rituals. Our “flame war” is apparently
held in person in their land and called “project meeting”.
-Alan Cox [on “Suits”]