openskills.info
Course catalog
Course Preview

Database Privilege and Access Control

Database privilege and access control is the part of a database that decides which identity may connect, which data or administrative objects it may use, and which operations it may perform. Accounts, roles, grants, ownership, and row policies turn an organization’s access rules into checks the database enforces.

itDatabases and data storage

Don't Panic — Database Privilege and Access Control

Database privilege and access control is the database's internal bouncer. It does not decide whether a password or token is genuine; that is authentication's job. It decides whether the resulting database identity may carry out this particular operation on this particular object. The distinction is less glamorous than a spy film and considerably more useful when a login succeeds but a query does not.

The machinery has a pleasingly bureaucratic shape. A principal is the person, service, or workload that connects. A role packages access around a responsibility. A privilege names an allowed operation and its scope. The database combines direct grants, role memberships, ownership, public defaults, and policies into effective access. This is why one neat-looking role does not settle the matter. Access can arrive by a side door wearing a perfectly respectable badge.

Scope is the part that keeps a small request from becoming a large mistake. Reading three tables calls for a narrow read role, not global read access or ownership. A migration process needs authority to create objects in one schema, not the keys to account management. Ownership deserves its own wary glance because owners can often alter, drop, or pass access onward. Grant and admin options are similarly not decorative ribbons; they decide who may redraw the access map.

Row-level security adds a second gate after broad table access. A principal can have permission to read a table yet see only rows accepted by a policy. That is useful when one table serves separate tenants or departments. It also explains a familiar small mystery: a query can run without error and still return no rows. Owners and administrators may bypass ordinary policies, so testing only with a powerful account is a fine way to certify the wrong thing.

Views and routines have their own trick. Invoker rights use the caller's authority. Definer rights use authority tied to the stored object. The latter can expose one narrow operation without revealing the base tables, but it becomes an escalation path when the owner has excess authority or the code accepts unsafe input. Databases are admirably literal about this; they do exactly what the authority path says, including the bits nobody meant to draw.

Start with the Introduction for the complete authorization flow and the vocabulary. Use the Slides when you need the access graph, scope ladder, and second gate in one view. Keep the Cheatsheet nearby when diagnosing a denial or reviewing ownership, delegation, and future-object drift. The practice material then turns the model into a local PostgreSQL test: grant the narrow path, test a permitted read, and test the neighboring operation that must remain forbidden.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources