Hologres supports three permission models: the standard PostgreSQL authorization model, the simple permission model (SPM), and the schema-level permission model (SLPM). This topic explains how to check which model is active and how to switch between models.
Check the current permission model
Use either of the following methods:
HoloWeb: Go to Security Center > DB Authorization. For details, see DB Management.
SQL: Run the following commands to check whether SPM or SLPM is enabled.
-- Check whether SPM is enabled. SHOW hg_experimental_enable_spm; -- Check whether SLPM is enabled. SHOW hg_enable_slpm;
Switch from SPM to the standard PostgreSQL authorization model
Prerequisites
Only a superuser can disable SPM.
What happens after the switch
After SPM is disabled, the public role retains the following permissions:
| Object type | Permissions retained |
|---|---|
| Public schema | USAGE, CREATE |
| Database | CONNECT, TEMPORARY |
| Functions and procedures | EXECUTE |
| Language, data types (including domains) | USAGE |
| Tables, views, materialized views, table columns, sequences, foreign data wrappers, foreign servers, non-public schemas | None |
The admin, developer, writer, and viewer user groups each retain permissions on existing objects only. These permissions do not extend to new database objects. The user groups themselves are not deleted.
Disable SPM
-- Disable SPM.
CALL spm_disable();
-- (Optional) Clean up user groups.
CALL spm_cleanup('dbname');Before running spm_cleanup, make sure no SQL statements are running on the database. Running cleanup while queries are active may fail and affect your service. For easier management, leave user groups in place rather than deleting them.Switch from the standard PostgreSQL authorization model to SPM
-- Enable SPM for the current database.
CALL spm_enable();
-- Update the owner of existing objects in the DB to 'developer' to be managed by SPM.
CALL spm_migrate();If a newly added account reports a permission error after switching, the object migration may be incomplete. Run CALL spm_migrate(); multiple times.If you see the error ERROR: cannot enable Simple Privilege Model for db=[xxxxxx] because roles conflict, see Troubleshooting.
Switch from SPM to SLPM
There is no direct path from SPM to SLPM. Switch via the standard PostgreSQL authorization model:
Disable SPM and revert to the standard model.
Enable SLPM.
-- Disable SPM.
CALL spm_disable();
-- Clean up SPM system roles.
CALL spm_cleanup('dbname');
-- Enable SLPM.
CALL slpm_enable();
-- Update the owner of existing objects in the DB to 'developer' to be managed by SLPM. This step is required.
CALL slpm_migrate();If a newly added account reports a permission error after switching, the object migration may be incomplete. Run CALL slpm_migrate(); multiple times.If you see the error cannot enable slpm for database xxxxx because roles conflict., see Troubleshooting.
Switch from SLPM to SPM
There is no direct path from SLPM to SPM. Switch via the standard PostgreSQL authorization model:
Disable SLPM and revert to the standard model.
Enable SPM.
-- Disable SLPM.
CALL slpm_disable();
-- Clean up SLPM system roles.
CALL slpm_cleanup('dbname');
-- Enable SPM.
CALL spm_enable();
-- Update the owner of existing objects in the DB to 'developer' to be managed by SPM.
CALL spm_migrate();If a newly added account reports a permission error after switching, the object migration may be incomplete. Run CALL spm_migrate(); multiple times.If you see the error cannot enable spm for database xxxxx because roles conflict., see Troubleshooting.
Troubleshooting
Roles conflict error
Symptoms: One of the following errors appears when enabling SPM or SLPM:
ERROR: cannot enable Simple Privilege Model for db=[xxxxxx] because roles conflictcannot enable slpm for database xxxxx because roles conflict.cannot enable spm for database xxxxx because roles conflict.
Cause: The model was previously enabled, and its system roles still exist in the database.
Fix: Enable the model in recovery mode by passing 't' as the argument.
For SPM:
-- Enable SPM in recovery mode.
CALL spm_enable('t');
-- Update the owner of existing objects in the DB to 'developer' to be managed by SPM.
CALL spm_migrate();For SLPM (when switching from SPM to SLPM — after disabling SPM and cleaning up system roles):
-- Disable SPM.
CALL spm_disable();
-- Clean up SPM system roles.
CALL spm_cleanup('dbname');
-- Enable SLPM in recovery mode.
CALL slpm_enable('t');
-- Update the owner of existing objects in the DB to 'developer' to be managed by SLPM. This step is required.
CALL slpm_migrate();For SPM (when switching from SLPM to SPM — after disabling SLPM and cleaning up system roles):
-- Disable SLPM.
CALL slpm_disable();
-- Clean up SLPM system roles.
CALL slpm_cleanup('dbname');
-- Enable SPM in recovery mode.
CALL spm_enable('t');
-- Update the owner of existing objects in the DB to 'developer' to be managed by SPM.
CALL spm_migrate();