[rt-devel] RT2 ACLs
Jesse
jesse at fsck.com
Wed Apr 4 16:22:16 EDT 2001
On Wed, Apr 04, 2001 at 01:45:09PM +0200, Arthur de Jong wrote:
>
> 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 :)
> 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 at west.nl - west consulting b.v. --
>
>
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
>
--
jesse reed vincent -- root at eruditorum.org -- jesse at 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"]
More information about the Rt-devel
mailing list