Skip to main content

Permissions Tab: Reference

This page is the source of truth for the in-app Explain this panels on the Schema Explorer detail view's Permissions tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

Permissions are collected for PostgreSQL, Microsoft SQL Server, Oracle, and MongoDB — on MongoDB the database is the schema scope, and its users and roles come from the engine's own commands. Redis and Valkey have no schema permission model and are not covered here.

Users​

The number of user principals with permissions on this schema — identities that can log in, as opposed to roles that only group privileges.

How it's calculated​

  • The agent collects principals from the engine's own catalogs: PostgreSQL roles that can log in, SQL Server database users, Oracle users, MongoDB users from the usersInfo command.
  • Counted from the most recent permissions snapshot for this schema.

Reading it​

Compare it against your team's size plus the service accounts you know about. A count that outgrows that sum means credentials are accumulating — former staff, one-off debugging accounts, or copies of service users. The table below names each one.

Roles​

The number of role principals with permissions on this schema — groupings that hold privileges and pass them to their members, rather than identities that log in.

How it's calculated​

  • The agent collects roles from the engine's catalogs: PostgreSQL roles without login, SQL Server database roles, Oracle roles, MongoDB roles from the rolesInfo command.
  • Counted from the most recent permissions snapshot for this schema.

Reading it​

Healthy setups have few, well-named roles and many members. Many roles with one member each is permission management by copy-paste — every access review gets harder. Click a role in the table to see its members and what it inherits.

Full Access Roles​

The number of principals whose privileges on this schema classify as full access — read, write, and structural control together.

How it's calculated​

  • Logstag classifies each principal's collected privilege flags into a level; a principal holding the full read-write-execute spread for the engine lands here.
  • Counted from the most recent permissions snapshot.

Reading it​

This is the tile to keep small. Every principal counted here can read the data, change the data, and change the structure — each one is a full-blast credential if leaked. The classic finding is an application service account with full access when it needs read-write at most; the table below shows exactly which flags earn each principal its level.

Read-only Roles​

The number of principals whose privileges on this schema classify as read-only — they can query, and nothing else.

How it's calculated​

  • Logstag classifies each principal's collected privilege flags into a level; principals holding select-style privileges without write or structural flags land here.
  • Counted from the most recent permissions snapshot.

Reading it​

A healthy number here is a good sign — it means reporting tools, analysts, and dashboards were given the least privilege that works. If this tile is near zero while Full Access is not, read-only consumers are probably borrowing write-capable credentials, which is the finding worth fixing first.

User and Role Permissions​

Every user and role with permissions on this schema, with a privilege matrix showing what each can do. Click a row for the full principal detail — granted privileges, role memberships and members, and grant metadata where collected.

Columns​

  • User/Role — the principal's name.
  • Type — User (can log in) or Role (groups privileges).
  • Privilege columns — Select, Insert, Update, Delete, Truncate, and Execute: a check means the principal holds that privilege somewhere in this schema.

The matrix is schema-level: it answers "can this principal do X in this schema," not which individual table each grant sits on. Engines also expose engine-specific privileges beyond these six (ownership and control flags, grant options); the common matrix keeps engines comparable, and the principal detail shows the fuller picture.

Source by engine​

EngineSource
PostgreSQLpg_roles with ACLs from the schema's objects, plus role membership from pg_auth_members
SQL Serversys.database_principals and sys.database_permissions (schema- and object-level grants), with role membership from sys.database_role_members
Oracledba_users, dba_roles, and object grants from dba_tab_privs
MongoDBthe usersInfo and rolesInfo commands — the database is the schema scope

On Oracle, a principal's detail also lists instance-wide system privileges where collected — including ANY-style privileges and admin options, which reach beyond this schema and deserve the closest review.

How it's calculated​

  • The agent collects permissions with the schema inventory: roughly every 10 minutes on PostgreSQL and MongoDB, every 4 hours on SQL Server and Oracle with default intervals. The table shows the most recent snapshot.

Reading it​

Read it column-first: the Delete and Execute columns are where surprises live. Then read row-first for any principal you don't recognize — its detail shows where the access comes from (direct grant vs inherited role), which is the difference between revoking one grant and restructuring a role.

Permission Change History​

A log of permission changes on this schema: grants, revokes, and role membership changes, newest first.

Columns​

  • Timestamp — when the change was detected.
  • Principal — who the change applied to.
  • Action — Grant, Revoke, Add member, or Remove member. Filterable.
  • Description — what changed.
  • Changed by — the grantor context, where the engine records one. Filterable.

How it's calculated​

  • History is derived by comparing consecutive permission snapshots, so a change is detected once the next snapshot lands — within about 10 minutes on PostgreSQL and MongoDB, up to 4 hours on SQL Server and Oracle with default intervals. The timestamp is the detection time, not the exact moment the statement ran.
  • The section always renders, even when empty, so an empty log is a statement — no recorded changes — rather than a missing feature.

Reading it​

This is the quiet audit trail: a Revoke that nobody planned means access cleanup happened outside process, and a Grant to an unfamiliar principal is worth tracing the same day. For PostgreSQL, grants also appear as first-class change records on the Changes tab — the two views cross-check each other.