<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Raed,<br>
<br>
>From my evaluations when scrutinizing the DB, I've noticed that it
seems ANY query saved by group (OH, this is on 3.6.4. I haven't had a
chance yet to REALLY look at the DB from a 3.8.x view) will always want
to check permissions for a single user that wants to look at that query
to see if that user is in the group. You say it is happening alot. Does
that mean this security check happens regardless of the user?
Regardless of the query? Is this GroupID a <i>system</i> group? If so,
is this query saved as a <i>system</i> query? There might be something
in these relationships that is escaping your notice. I've found, at
least in the past, that a <i><b>LOT</b></i> of the <i>time-consuming</i>
search problems are related to user/group membership/privileges. Hope
this helps you in de-bugging the problem.<br>
<br>
Kenn<br>
LBNL<br>
<br>
On 2/8/2010 9:41 AM, Raed El-Hames wrote:
<blockquote cite="mid:4B704CAF.10102@vialtus.com" type="cite">Thanks
for your response Ken ,
<br>
I traced it down to missing entry in CachedGroupMembers;
<br>
<br>
When I upgraded my dev box from 3.6.3 to 3.8.7 I ran
shrink_cgm_table.pl, which for some reason (maybe something in my
system) deleted the following row:
<br>
<br>
mysql> select * from CachedGroupMembers where id = 2;
<br>
+----+---------+----------+------+-------------------+----------+
<br>
| id | GroupId | MemberId | Via | ImmediateParentId | Disabled |
<br>
+----+---------+----------+------+-------------------+----------+
<br>
| 2 | 2 | 1 | 2 | 2 | 0 |
<br>
+----+---------+----------+------+-------------------+----------+
<br>
<br>
This is the row that tells the RT::SystemUser that its a member of
itself , and its the row that ACLs and Principals are checked against.
<br>
The fact it was missing, it made the system loop through the queue
checking acls for the RT user.
<br>
so I added it via sql, and that problem is resolved, however :
<br>
<br>
I do have another problem now, which is repeated :
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE GroupId = '2034'
AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
176 Query SELECT * FROM CachedGroupMembers WHERE
GroupId = '2034' AND MemberId = '1'
<br>
<br>
No doubt its missing entries in the database ? (for the curious 2034 is
a defined user group) , why its checking if the SystemUser is a member
of that group is beyond my little brains.
<br>
<br>
Again Any help will be appreciated
<br>
<br>
Roy
<br>
<br>
<br>
<br>
<br>
Ken Crocker wrote:
<br>
<blockquote type="cite">Raed,
<br>
<br>
The only thing I can think of to help de-bug this is to list the
privileges you've set and then compare that list to what you see in the
ACL table. Unless, of course, you have Rights Matrix installed. That
would also help. I don't know if "Rights Matrix" works on 3.8.x, but it
certainly is worth a try.
<br>
<br>
<br>
Kenn
<br>
LBNL
<br>
<br>
On 2/8/2010 8:50 AM, Raed El-Hames wrote:
<br>
<blockquote type="cite">Maybe this time I'll get an answer ..
<br>
RT-3.8.7 NO customisation apart from css
<br>
DBIx - 1.56 apache2,mod_perl2
<br>
<br>
I am seeing a lot of queries (1146 of them)
<br>
<br>
SELECT ACL.id FROM ACL, Groups, Principals, CachedGroupMembers WHERE
(ACL.RightName = 'SuperUser' OR ACL.RightName = 'ShowACL') AND
Principals.Disabled = 0 AND CachedGroupMembers.Disabled = 0 AND
Principals.id = Groups.id AND Principals.PrincipalType = 'Group' AND
Principals.id = CachedGroupMembers.GroupId AND
CachedGroupMembers.MemberId = 1 AND ACL.PrincipalType = Groups.Type
AND ((ACL.ObjectType = 'RT::System' AND ACL.ObjectId = 1) OR
(ACL.ObjectType = 'RT::Queue' AND ACL.ObjectId = 4)) AND Groups.Domain
= 'RT::System-Role' AND Groups.Instance = '1' LIMIT 1
<br>
<br>
<br>
The only changes I see between these queries are
<br>
- variation between ShowACL and ModifyACL
<br>
- ACL.ObjectId = x (where x is the id foreach active queue in the
system -- we have 116 active queues)
<br>
<br>
<br>
1- The first question that comes to mind what are we calling this
lookup anyway, if the RT System user does not have permission on a
queue, then the system is broken, so this lookup should be done
differently and else where??
<br>
2- Where is this called from so I can disable it (unless some one can
answer question 1 and enlighten me as to why its there)??
<br>
<br>
Any help will truly be appreciated , these 1147 for 116 queues, my live
system have twice the amount of queues and my concerns that I will end
up with 3000 or so pointless queries with every page.
<br>
<br>
Please please help.
<br>
<br>
Roy
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
<a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a>
<br>
<br>
Community help: <a class="moz-txt-link-freetext" href="http://wiki.bestpractical.com">http://wiki.bestpractical.com</a>
<br>
Commercial support: <a class="moz-txt-link-abbreviated" href="mailto:sales@bestpractical.com">sales@bestpractical.com</a>
<br>
<br>
2010 RT Training Sessions!
<br>
San Francisco, CA, USA - Feb 22 & 23
<br>
Dublin, Ireland - Mar 15 & 16
<br>
Boston, MA, USA - April 5 & 6
<br>
Washington DC, USA - Oct 25 & 26
<br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at <a class="moz-txt-link-freetext" href="http://rtbook.bestpractical.com">http://rtbook.bestpractical.com</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>