Martin Staudigel · Feb 19, 2021

Security Issue: Auditlog - Attempt to access a protected global

Hello community,

I would like to report about a security issue, that engages us for some time meanwhile.

We configured a restricted user to read data from a csp page to feed our nagios server with information about configuration items we would like to have an eye upon. The configuration of this user is the same in our production and in our development environment. The called method mainly reads data from lookup tables by sql queries and writes data to a temporary table, which is deleted in the begining.

The weird thing is, that both on DEV an PROD the script terminates without any obvious error, the result is returned to and evaluated by nagios, but on our production machine we observe errors in the audit log, which complain an attempt to access a protected global. As this script is called every few minutes and causes a different number of entries (most of the time it's four or five) the audit log is flood with this kind of error messages. Not surprisingly, a call with a user having administrative rights doesn't cause any problems. The same setup on the development machine also doesn't cause any problems.

I attached a PDF file containing the error and some code and configuration snippets to get an idea. As the script runs without error, we don't know how to find out which part causes the access violation an so it's hard for us to find out which part of the code or user-configuration has to be adjusted. We would really apprechiate any hint on how to narrow the problem or determine what to do to get rid of the  audittrail entry.


Martin Staudigel

Product version: HealthShare 2018.1
$ZV: Cache for UNIX (SUSE Linux Enterprise Server for x86-64) 2018.1.3 (Build 414_0_19402U) Mon Nov 18 2019 22:54:54 EST [HealthShare Modules:Core:15.032.9026 + Linkage Engine:15.032.9026]
0 224
Discussion (2)1
Log in or sign up to continue

IndexHash+7 tries to access ^rINDEXCLASS global from CACHESYS database.

As the user does not have R (or possibly W, but probably R) privilege on %DB_CACHESYS  resource the <PROTECT> event is raised.

To solve this you need either:

Hello Eduard,

thanks for your helpful reply. I assigned the role %DB_CACHESYS to the user, which grants R/W rights to some tables from the INFORMATION_SCHEMA schema. As the user still isn't allowed to login to neither management portal nor studio my basic demands are fullfilled, so I chose not to start an investigation which of the given tables causes the violation. This setting removes the unwanted entries from the auditlog, so the problem is solved from my point of view. Thanks again,


Martin Staudigel