Fine tuning access permissions for CSP application

Question

Question

Martin Staudigel · Apr 14, 2021

Hello,

fine tuning access permissions is a difficult issue in Caché, at least for me as it seems. More generally, I would be interested in how to find out which permission a user is missing when a permission violation is logged. In this specific case a user, created in (from my point of view) an identical way as on other instances, is not allowed to execute an operation within a CSP service on the messagebank (which however works on the other machines). Unfortunately, the message in the errorlog does not tell where exactly the access violation occurs, or what permission is missing. I attach a PDF with some screenshots. I would be very grateful for any advice on how to proceed with troubleshooting.

Thanks very much, regards,

Martin

Product version: Caché 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

error_details.pdf

Discussion (5)1

Log in or sign up to continue

Vic Sun · Apr 14, 2021

Martin,

This makes sense to me. Access to databases is controlled by that database resource setting, which can be customized and assigned to various roles. A role that is assigned %DB_%DEFAULT access will grant access to any databases that are controlled by that resource.

If you are concerned, you could review the other databases and make sure that you want your user to have access to the other databases secured by %DB_%DEFAULT. If you wanted more restriction, you could assign your databases a different resource other than %DB_%DEFAULT, such as having specific database resources for each database. That way, you only grant permissions for 1 specific database when granting the custom resource.

See documentation here:

Database Resources

Hope that helps.

1 0

score 3 · Answer 1 · 2021-04-14T07:28:22-04:00

For <PROTECT> errors, if you turn on auditing of protect errors, the audit log will often have more information about the exact place the error comes from. To do this, you will need to enable auditing system-wide via either the portal or ^SECURITY, make sure that auditing for the specific event you want (protect) is enabled, then reproduce the error.

There deliberately isn't much information about which permission is missing given to the user who got the error, to prevent a malicious user from mapping out info about the permissions needed.

score 0 · Answer 2 · 2021-04-14T08:55:40-04:00

I did, here are the details of the error, which was provoked again after enabling audit log for protect events. By the way - because I didn't mention it earlier - with an admin account the call works. Does this provide details about the source of the error?

score 0 · Answer 3 · 2021-04-14T09:15:33-04:00

Hello Martin,

The <PROTECT> error is on the UKERALL database so I would start there. The first thing that comes to mind for me is whether that database has a different resource securing it, as under the "Roles" list I don't necessarily see a role that seems to correspond to that database exactly. This is dependent on how your roles and database resources are configured.

Does your admin user have %ALL or some subset of permissions? If not %ALL, you could try comparing the admin user's permissions to the user getting the error here.

score 0 · Answer 4 · 2021-04-14T10:13:36-04:00

Hello Vic,

yes, our admin users are provided with %ALL privileges, but it seems like I finally managed to get things working. I don't understand in detail why it works, but I noticed that the configuration of the databases on the other hosts is different.

So I tried out adding the role %HS_DB_%DEFAULT to the user in question. With this additional role it seems to work.

It would still be interesting to know if there is an unnecessarily large expansion of permissions associated with this role that poses an unintended risk.

Thank you for your help!

Regards, Martin