Fix PostgreSQL permissions and data schema, and relevant docs

deployment/secure_research_environment/cloud_init/cloud-init-postgres.mustache.yaml

@@ -60,6 +60,13 @@ write_files:
       # Run user synchronisation every 10 minutes
       */10 * * * * postgres /usr/local/bin/pg_ldap_sync -vvv -c /etc/postgresql/12/main/pg-ldap-sync.yaml 2>&1 | logger -t SafeHaven
 
+  - path: "/etc/cron.d/db-role-update"
+    permissions: "0644"
+    content: |
+      # Trigger role updates every 10 minutes by writing a comment to the data schema
+      # Run at 1, 11, 21, 31, 41, 51 minutes past the hour so always after the user sync
+      1-59/10 * * * * postgres /usr/bin/psql -q -c "comment on schema data is 'Data schema can only be modified by Data Admins or System Admins';"
+
   - path: "/etc/cron.d/runonce"
     permissions: "0644"
     content: |
@@ -158,7 +165,7 @@ write_files:
   - path: "/opt/configuration/create-postgres-triggers.sql"
     permissions: "0444"
     content: |
-      {{{postgres_create_postgres_triggers.mustache.sql}}}
+      {{postgres_create_postgres_triggers.mustache.sql}}
 
   - path: "/opt/configuration/install-postgres-extensions.sql"
     permissions: "0444"

deployment/secure_research_environment/cloud_init/postgres_create_postgres_triggers.mustache.sql → deployment/secure_research_environment/cloud_init/resources/postgres_create_postgres_triggers.mustache.sql

@@ -9,8 +9,15 @@ DECLARE
 obj record;
 BEGIN
 IF EXISTS (SELECT usename FROM pg_user WHERE ((usename = CURRENT_USER) AND (usesuper='t'))) THEN
-    FOR obj in SELECT * FROM pg_user WHERE ((usesuper='t' or usecreatedb='t') AND (usename!='postgres') AND NOT pg_has_role(usesysid, '{{sre.domain.securityGroups.systemAdministrators.name}}', 'member')) LOOP
-    EXECUTE format('ALTER USER "%s" WITH NOCREATEDB NOCREATEROLE NOSUPERUSER;', obj.usename);
+    FOR obj in SELECT * FROM pg_user 
+        WHERE usesysid NOT IN (
+            SELECT member FROM pg_auth_members
+            WHERE roleid = (
+                SELECT oid FROM pg_roles 
+                WHERE rolname = '{{sre.domain.securityGroups.systemAdministrators.name}}'))
+            AND NOT usename = 'postgres'
+    LOOP
+        EXECUTE format('ALTER USER "%s" WITH NOCREATEDB NOCREATEROLE NOSUPERUSER;', obj.usename);
     END LOOP;
     FOR obj in SELECT * FROM pg_user WHERE (pg_has_role(usesysid, '{{sre.domain.securityGroups.systemAdministrators.name}}', 'member')) LOOP
     EXECUTE format('ALTER USER "%s" WITH CREATEDB CREATEROLE SUPERUSER;', obj.usename);

docs/source/roles/system_manager/manage_users.md

@@ -17,10 +17,13 @@ A helper script for doing this is already uploaded to the domain controller - yo
 
 ### {{lock}} SRE Security Groups
 
-Each user should be assigned to one or more Active Directory "security groups", which give them access to a given SRE with appropriate privileges. The security groups are named like so:
+Each user should be assigned to one or more Active Directory "security groups". The key difference between these groups is the level of privilege they have when manipulating databases within the SRE.
 
-- `SG <SRE ID> Research Users`: Default for most researchers. No special permissions.
-- `SG <SRE ID> Data Administrators`: Researchers who can create/modify/delete database tables schemas. Given to a smaller number of researchers. Restricting this access to most users prevents them creating/deleting arbitrary schemas, which is important because some SREs have their input data in database form.
+- `SG <SRE ID> Research Users`: Almost all researchers should be in this group. No special permissions. Allows users to log in to `<SRE ID>`.
+- `SG <SRE ID> Data Administrators`: Researchers who can create/modify/delete tables in the `data` schema on databases within `<SRE ID>`. `SG <SRE ID> Research Users` can only read these tables. Restricting this access prevents most users from creating/deleting arbitrary tables, which is important because some SREs have their input data in database form.
+- `SG <SRE ID> System Administrators`: Researchers who have full superuser privileges on databases within `<SRE ID>`. Users in this group have full access to the databases and can manipulate them in any way they choose.
+
+Typically, users with either of the latter two roles should also have the `Research Users` role to allow them to log in to the SRDs within the SRE.
 
 (generate_user_csv)=