Is there any Special backend access controls on sys_choice and sys_user_has_role table???

mandy2 · ‎10-21-2015

Hello Everyone,

Do anybody know if SNOW has any backend controls on sys_choice and sys_user_has_role table? I have a client script need to query data from the two tables, but always get failed to set values. So I am thinking probably the ACL restricted the access to the table.

OOB ACL on sys_choice table, specified the 3 roles

So I disabled all the OOB read ACLs on sys_choice, and new create one to let every one can read record, didnt speficy any role.

Then I test the access by using a client script

while when I impersonate to user who only has hr_agent role, alert pop up, but unable to retrive the value from sys_choice table, even I new create the ACL to let every one have access on sys_choice table.

But If I keep disable OOB ACLs, and add one of the specified role, i.e. Personalize to test user, then the alert can pop up with the correct value which retrived from sys_choice table.

So I am thinking probably SNOW have access controls on sys_choice table somewhere else. similar issues for sys_user_has_role table.

Do anyone have any ideas or suggestions on this? Thanks in advance.

manikorada · ‎10-21-2015

Wei,

What I would do is:

1) Debug Security Rules

2) Impersonate the User

3) Now type sys_choice.list

4) check if there are any ACL's blocking those.

mandy2 · ‎10-22-2015

Hi Mani,

Thanks for your reply first.

I tested with your steps, user who has hr_agent role, only can see one field Label in sys_choice table. Be noted, I have disabled all OOB read ACLs on that table.

sergiu_panaite · ‎10-21-2015

Hello Wei,

We're not talking here only about sys_choice ACLs. If sys_choice ACLs are inactive or don't exist, platform will check the ACLs at the next level until either an ACL is match or otherwise by default we will deny access to the record. This is explained more here:

http://wiki.servicenow.com/index.php?title=Using_Access_Control_Rules#Granting_or_Denying_Access

"If the user fails to meet the permissions required by the first rule, the system searches for the next matching ACL rule. For each matching ACL rule, the user has a chance to meet the required permissions in order to access the object. The system stops searching for matching ACL rules if the user ever meets a matching ACL rule's permissions. If the user cannot meet the permissions of any matching ACL rules, the system denies the user access to the object."

In your case I bet you get access denied to the record because of "*" ACL with operation "read" for type "record" which says:

"To read records on any table the following must apply:

user has the admin role

OR

glide.sm.default_mode = allow which allows access to all tables in the absence of any other security rules (ACLs)"

Content of that ACL:

gs.hasRole('admin') || gs.getProperty('glide.sm.default_mode') == 'allow'

By default "glide.sm.default_mode" is set to "deny".

Hope this helps.

Regards,

Sergiu

mandy2 · ‎10-22-2015

Hi Sergui,

Thanks for you light. I figured out the issue now.

Checked again, I didnt disable the OOB ACL of sys_choice.* , I am able to query data from sys_choice table after inactive it.

looks like the platform checked this one and denied the access, even I have an ACL to let everyone can access the table

For sys_user_has_role, the "Role" in that table is a reference type of column, which will retrieve data from sys_user_role, hence we need to modify the ACLs on sys_user_role as well to allow the access.

Appreciated again!