ACL allowing approver modification if user is logged in

[Luiz Lucena]

Hi everyone, 

Who else noticed this ACL introduced in 2023 allowing write operation to the Approver field?



I couldn't find this ACL in my PDI (brand new) but in our company instances (DEV, TEST and PRD) this ACL was updated by a patch or upgrade. 

We were just informed by one of the application admins that an ITIL user was updating the approvers at their own will, which for us, is a concerning issue because some application accesses are controlled by SOX. 

I made the approver field read-only and then head over our lower environment to check this ACL and was able to reproduce by disabling that ACL.

Just would like to know if anyone else had the same issue.

[Chaitanya ILCR]

Hi @Luiz Lucena ,

just check if anyone from your organization has enabled this property

glide.security.allow_unauth_roleless_acl

 this should be true to be able to update the field right

just check who has last updated it

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Luiz Lucena]

Hi @Chaitanya ILCR 

That property doesn't exist in our environment. 
And the last update in that ACL is shown in the last screenshot I sent earlier. 
system@snc.maint,admin  

Do you have that ACL?

I've found this KB in NOW Support, looks like they applied these changes to various ACLs pre-existent in customer instances. 

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1555339

Not sure what the issue was for them to do such thing, but certainly now is broken where before was not.

[Chaitanya ILCR]

Hi @Luiz Lucena ,

No I don't see that ACL in any of my company instances nor in My PDIs

better raise a case with servicenow to get more details on how it got installed and why

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Luiz Lucena]

Hi @Chaitanya ILCR 

Based on the KB I mentioned I was able to understand the issue. 

Basically, ANY custom ACL without a role, condition or script, was addressed by that ServiceNow Maintenance.

I understand they were trying to improve overall security in the instance, but the way they approached make other stuff break, like the one mentioned in this post.

Thanks for your input here.