debugging security constraint errors

jackiemcnabb
Giga Contributor

when user is viewing a list of incidents (or tasks) they will get a message "Some rows removed from this list by Security constraints"  What does this mean and how can I figure out what it causing it?  We get it on various screens and chalk it up to permissios of some kind but I would really like to know how to get to the bottom of it becuase users who seemingly have the same exact groups and roles are seeing differnt records....  Please help.

1 ACCEPTED SOLUTION

randrews
Tera Guru

there are two ways to debug this... quick and dirty and longer/slower...



quick and dirty... go to system security and disable all read rules on the table...


        now verify they load ok as the user.


        turn the rules back on one at a time and see which one breaks the user




longer slower...


        as admin in system security turn on debug security rules.


        impersonate the user


        now try to load the list view


        the bottom of the page will show ALL security rules and the results... look for the one with the red X in the left side <or ones>


        the boxes will tell you if it failed on condition, script, roles, or all three.. and you can fix the rule from there...




in a case like this i will generally NOT update the existing rule but create a new read rule to grant access.


View solution in original post

6 REPLIES 6

jake_mckenna
ServiceNow Employee
ServiceNow Employee

I would review the ACL permission against the tables to see what is required to READ the records. The ACL level permissions are adding this message. Normally a better option would be to look into adding a before query Business rule that would remove the records that a user was not supposed to view if that was the intended outcome.



Example script: A default before-query business rule




To debug the ACLS i would also consider turning on the debug Debug Security under the System Diagnostics Application to help with understanding which rule is triggering the deny.


randrews
Tera Guru

there are two ways to debug this... quick and dirty and longer/slower...



quick and dirty... go to system security and disable all read rules on the table...


        now verify they load ok as the user.


        turn the rules back on one at a time and see which one breaks the user




longer slower...


        as admin in system security turn on debug security rules.


        impersonate the user


        now try to load the list view


        the bottom of the page will show ALL security rules and the results... look for the one with the red X in the left side <or ones>


        the boxes will tell you if it failed on condition, script, roles, or all three.. and you can fix the rule from there...




in a case like this i will generally NOT update the existing rule but create a new read rule to grant access.


so we did this and it looks like the vtb_task/read and the vtb_card/read are both returning false for the script


answer = new VTBBoardSecurity().canAccess(current.board);



How can we look at the code in this script - can't seem to find it anywhere.


edwajs
ServiceNow Employee
ServiceNow Employee

The code you are looking for is in the VTBBoardSecurity script include.



canAccess: function(boardRecord) {


  // if they are the owner of the board, they can access it


  if (boardRecord.owner == gs.getUserID())


        return true;


  return this.isBoardMemberOf(boardRecord.sys_id);


},



There are several more functions in this script include which are called from isBoardMemberOf(), but basically you can access the board if you are the owner or a member of the board.