Illegal access in sandbox to public GlideScriptable GlideSystemUtilDB / GlideSystemUtilScript

[G_Ede]

Hi All,

We're in the process of configuring a brand new instance of Jakarta and have noticed a couple of errors starting to appear in the log at the same time every day.   I've searched around for hints on what could be causing these, but I haven't found anything to help yet!

The errors are quite long (details attached) but they start with...

Problem when trying to get a Rhino object: java.lang.SecurityException: Illegal access in sandbox to public GlideScriptable GlideSystemUtilDB

...or...

Problem when trying to get a Rhino object: java.lang.SecurityException: Illegal access in sandbox to public GlideScriptable GlideSystemUtilScript

As they happen at the same time every day, my first instinct was a scheduled job, but as far as I can see there are only three running around that time and all three appear to be unmodified out of the box:

• LDAP Refresh
• Stock Rule Runner
• UsageAnalytics Count Persistor

My best guess is that something has been modified somewhere that one of these jobs touches which has caused the error to start appearing, but I haven't been able to gather enough information to help me track down what.

Does anyone have any suggestions on what might be causing these errors, or any tips on how to gather more information to help investigate the root cause?

[bernyalvarado]

Hi Graeme,

Are you using GlideSystemUtilDB and/or GlideSystemUtilScript anywhere within the customizations within your instance (business rules, script includes, acls, etc...)?

Most likely you or your team haven't done any customization with those. Specially if you're configuring a brand new instance.

My recommendation will be to open a Hi support ticket so that ServiceNow support can log into your instance and provide guidance if those errors are expected or if there's something wrong with your instance.

Thanks,

Berny

[G_Ede]

Thanks Berny,

As far as I am aware no customizations have been made that make use of either of these.   I did some searching around as well using the Full Text Search on the script tables that I could find (e.g. sys_script_include) and could only find a handful of scripts that appear to mention them.   All of those were out of the box.

I'll open a HI ticket and if I get any further forward I'll update here.

[bernyalvarado]

Cool! Yeap. that sounds like the right course of action to take then

[G_Ede · Accepted solution]

ServiceNow support have resolved this (thanks Steve!)

Just in case this helps anyone else, from our HI Incident:

Most Probable Cause: A Usage Analytics statistic job configuration uses a call to gs.beginningOfLast90Days() which triggers the errors seen in Jakarta Patch 1 Hot Fix 1

Solution Proposed: The use of gs.beginningOfLast90Days() does not trigger the error in Jakarta Patch 2 or later, therefore updating to this patch release or later should result in the errors no longer being generated.

This was fine for us, as we were already scheduled to upgrade to Jakarta Patch 3 as part of the quarterly patching, however, support managed to find a work-around that meant the problem could be immediately resolved:

Workaround: The UsageAnalytics engineering team have added an override to their central instance which will inhibit the particular UA job that triggers the error on your development instance.   I have asked them to add the same override for your production instance.   This should mean that the errors will not be seen on subsequent executions of the scheduled job, and means that updating to Jakarta Patch 2 or later is not required.

This stopped the errors appearing immediately.