[rt-users] RT improving security/privacy

[Kenneth Crocker]

Holland,


	That seems like a lot of work to me when all you really need to do is 
use the privileges to not allow these people the ability to do all that. 
Sounds like you have allowed too much at the global level. If you'd 
answer the following questions for me, I think we can come up with a 
prudent scheme that will give your users robust abilities and still 
preserve the security you're after: What rights have you set up for 
Global access for what groups/users? What kind of function are your 
queues used for? How many? What kind of groups have you set up and what 
are their responsibilities per queue? Who works on tickets and what kind 
of rights do you want them to have as opposed to the users sending in 
requests? Who administrates your RT? Thanks.

Kenn
LBNL

On 4/4/2008 6:10 AM, holland holland wrote:
> Dear all,
> 
> My problem started with people putting by mistake users on admincc,
> with the terrible effect of having those people viewing comments.
> 
> Basically I'm trying to detect AdminCc (watchers) set on ticket and Queues.
> 
> I think of 3 possible solutions:
> 
> 1/
> A scrip that prevent certain users of being put as AdminCc (For Ticket
> and Queue):
> 
> Custom action preparation code:
> -----------------------------------------------
> 
> Track when Admincc added at ticket or Queue level.
> Check against list of authorized users (authorized to be on admincc)
> 
> Custom action cleanup code:
> -----------------------------------------
> 
> send alert or others.
> 
> 
> I started with this piece, but it only check at ticket level:
> 
> my $transactionType = $self->TransactionObj->Type;
> my $watcherType = $self->TransactionObj->Field;
> if (($transactionType eq 'AddWatcher') and ($watcherType eq 'AdminCc')) {
>  return 1;
> }
>  return undef;
> 
> 
> 
> 2/
> 
> When pressing "Save Changes" button,  end user will be warned that
> this user cannot be set as admincc (not found against list of
> authorized users).
> 
> By far the best solution to me.
> 
> 
> 
> 3/
> SQL in a cronjob, but not pro-active enough.
> 
> 
> I found this SQL statement (at the ticket level) so far:
> ---------------------------------------------------------------------------
> 
> 
> SELECT DISTINCT
>    t1.id Ticket_id,
>    g2.id RoleGroup_id,
>    g2.Type Role_Type,
>    cgm3.MemberId RoleMember_id,
>    p4.PrincipalType,
>    u5.Name
> FROM
>    Tickets t1,
>    Groups g2,
>    CachedGroupMembers cgm3,
>    Principals p4,
>    Users u5
> WHERE
>    t1.id > 10000 AND
>    g2.Domain = 'RT::Ticket-Role' AND g2.Instance = t1.id AND
>    cgm3.GroupId = g2.id AND
>    p4.id = cgm3.MemberId AND
>    p4.Disabled = 0 AND
>    p4.PrincipalType = 'User'
>    AND g2.Type = 'AdminCc'
>    AND u5.id = p4.id;
> 
> 
> 
> ---------------------------------------------------------------------------------------------------
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>