Access Rights of Users with no Roles

[Boris Livertovs]

Hello all,

I would like to know what a user is able to access (specifically tables) with no roles assigned to it?

The use case would be as follow:

As part of role management I am about to do a matrix of all roles and tables that shows what roles can do on which tables based on underlying ACLs. Essentially what CRUD operations does a given role have on any table. Once I got this information, I am better able to assign needed roles to groups and users or create new roles which grant the needed access to the required tables.

The table [sys_security_acl_role] gives insight into it already, but not enough.

Lets take for example the Demand [dmn_demand] table:

There are no explicit create ACLs for the corresponding roles [it_demand_manager] or [it_demand_user], which was quite suprising, as they should and are able to create records in the given table. In a bit of experimenting I did find that any user (even users with no roles) have access to and can create demand records.

This means that to get a more complete picture of what a user with any role can do on any table I also have to consider users with no roles, as all users would have those access rights, too. 

So in my quest to get all accessable tables for users with no roles I did stumble on the [activitydef_scriptfile] table.

This table has no ACLs of its own but does get ACLs inherited from its parent table [sys_metadata] (only field ACLs) and the general " * "- ACLs.

Of course my "no-roles-user" couldn't access this table, yet the question was why? After deactivating those " * "-ACLs the "no-roles-user" stil couldn't access the table, even after deactivating the parent table ACLs.

Using the script debugging on ACLs didn't give me any new insights, as it didn't show any ACLs that deny access. (Parent table and general ACLs activated and not)

This means there is something other than ACLs blocking the access but I can't find what it is.

Does anyone know what it could be? 

TL;DR: I want to know what can give and deny access to any table and user regardless of assigned role. Or in another way I want to know what tables users with no roles can access and how I am able to find that.

Edit: The Demand table does have a create - ACL which isn't bound to any role and therefore gives create access even to ALL users (even those without any roles). But what about tables without any ACLs of their own as is the case with [activitydef_scriptfile] table?

[Jeff Currier]

Boris,

I don't know the answer to the question of how to get a list of all tables.  This would be an expansive list as you would want to look at both read (access) and create (write) ACLs, plus business rules and other constraints are involved.

As for the demand, table, any user, i.e. requestors, can create a demand, so it isn't related to those specific roles you mention.

This is the language for that:

A requestor can create a new demand and also add other requestors as collaborators. A collaborator on a demand can modify the demand, as long as it hasn't been submitted to a demand manager. They can create a demand but only view the business case form.

This would be similar to the incident and request tables.

Sorry, I know this doesn't really answer you question, but I wanted to explain the demand part

[Boris Livertovs · Accepted solution]

A bit late but I thought I'll still update this post for anyone looking for similar problems.

1. Checking if a user with no roles (commonly know as ESS User) has permissions to a table is possible through impersonation to that user and using the GlideRecord .canCreate(), .canRead(), .canWrite(), .canDelete() functions.
A code example would be:

var impersonatedUser = new GlideImpersonate();
    impersonatedUser.impersonate('sys_id of a user');

var table = new GlideRecord('tablename');
var tableCanCreate = table.canCreate();
var tableCanRead = table.canRead();
var tableCanWrite = table.canWrite();
var tableCanDelete = table.canDelete();

// important to impersonate back to yourself after permission checks have been made
impersonatedUser.impersonate(gs.getUserID());

2. A table which doesn't own any kind of ACL to a particular operation grants permission to that operation only to the admin.