Difficulty trying to track down how a user has WatchAsAdminCC Privileges (when they should not)

RT Users
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We have a fairly large RT install, and I have a queue in which it seems
most users somehow can add themselves as an AdminCC, when they should
not be able to (and I don’t want them to) as far as I can tell. I
believe that this means that 2 restrictions are not functioning
properly. The first is the ability of this privileged user to add an
AdminCC, and the second is the restrictions on who the target of and
AdminCC can be.

I did some searching, but most of the AdminCC threads seem to revolve
around AdminCC not notifying properly, which is not a problem I have.

Under Admin->Queues->(the queue in question)->Group Rights->Privileged
Users:
CommentOnTicket
CreateTicket
ReplyToTicket
ShowTicket
ShowTicketComments

But no “WatchAsAdminCC”. Same for unpriv, and everyone.

Under roles, nothing special but ShowTicket.

Under the user defined groups, there are 2 groups that have that right,
but they do NOT contain as a member the people who mistakenly obtained
permission to modify AdminCC.

Neither the person adding the AdminCC has queue modify permissions, nor
is the target person (an auto generated email address!) have permissions
“WatchAsAdminCC”. The user is not a SuperUser administrator either.

Under Admin->Queues->(the queue in question)->Group Rights->Privileged
Users: nothing has been selected. (Everything is handled via groups)

We’re on version 3.6.4.

I thought I was good with RT, but on this, I’m completely baffled.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/8BsACgkQxcV19bUNEEM9vgCgomzB7yLIQHCxcFeAJ7/xbXmt
/zwAoOVmf4X1mpuro2jctD18HFZYIqkU
=ZxNI
-----END PGP SIGNATURE-----

jon.vcf (356 Bytes)

2

Jonathan,

A couple of things to keep in mind. Person A is in group A. Person B is
on Group B. Neither groups allow “WatchAsAdminCc”. Group C has a
membership of Group A and Group B and allows the aforementioned right of
“WatchAsAdminCc”. So, even if you were to look at a group that
specifically lists the users ANd you were to see that the group does NOT
allow that right, they may still have that right via Group C. Groups can
be mebers of groups.
Also, not that you WOLD do it, but it COULD be possible that these users
were given that right as USers, not as members of a group. If it were
me, I would get the userIDs of each member that was doing this and find
out what membershipd they were in AND look at their individual rights a
Users.
Of course, if you have RightsMatrix, that would help immensly.

Kenn
LBNLOn 6/22/2009 1:56 PM, Jonathan Hartford wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We have a fairly large RT install, and I have a queue in which it seems
most users somehow can add themselves as an AdminCC, when they should
not be able to (and I don’t want them to) as far as I can tell. I
believe that this means that 2 restrictions are not functioning
properly. The first is the ability of this privileged user to add an
AdminCC, and the second is the restrictions on who the target of and
AdminCC can be.

I did some searching, but most of the AdminCC threads seem to revolve
around AdminCC not notifying properly, which is not a problem I have.

Under Admin->Queues->(the queue in question)->Group Rights->Privileged
Users:
CommentOnTicket
CreateTicket
ReplyToTicket
ShowTicket
ShowTicketComments

But no “WatchAsAdminCC”. Same for unpriv, and everyone.

Under roles, nothing special but ShowTicket.

Under the user defined groups, there are 2 groups that have that right,
but they do NOT contain as a member the people who mistakenly obtained
permission to modify AdminCC.

Neither the person adding the AdminCC has queue modify permissions, nor
is the target person (an auto generated email address!) have permissions
“WatchAsAdminCC”. The user is not a SuperUser administrator either.

Under Admin->Queues->(the queue in question)->Group Rights->Privileged
Users: nothing has been selected. (Everything is handled via groups)

We’re on version 3.6.4.

I thought I was good with RT, but on this, I’m completely baffled.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/8BsACgkQxcV19bUNEEM9vgCgomzB7yLIQHCxcFeAJ7/xbXmt
/zwAoOVmf4X1mpuro2jctD18HFZYIqkU
=ZxNI
-----END PGP SIGNATURE-----

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com