schema "security" tightened, typos fixed

Author: kmoppel

00_create_database.sql

@@ -1,9 +1,8 @@
+-- NB! Dropping databases will fail if there are sessions connected to it. In such cases connected users can be for exmple "killed" with:
+SELECT count(*) AS sessions_killed FROM (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'pg_features_demo' AND pid != pg_backend_pid()) a;
+
 DROP DATABASE IF EXISTS pg_features_demo;
 
-/*
--- NB! Dropping databases will fail if there are sessions connected to it. In such cases connected users can be for exmple "killed" with:
-SELECT count(*) AS sessions_killed FROM (SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'pg_features_demo') a;
-*/
 
 CREATE DATABASE pg_features_demo;
 

01_create_role.sql

@@ -1,9 +1,21 @@
 -- Create a role (a.k.a: user, login, group) that is allowed to log in.
 -- NB! By default roles are allowed to connect to all databases of a cluster. This does not mean that they can automatically access tables though.
 -- But if this is not wanted, per DB connections can be set up with "REVOKE/GRANT CONNECT ON DATABASE"
-CREATE ROLE demorole WITH LOGIN;
+
+CREATE ROLE demorole WITH LOGIN;    -- create a normal(unprivileged) user
 
 -- Will later be set up to only allow selecting data
 CREATE ROLE demorole_ro WITH LOGIN;
 
--- TODO Super, password, mention other auth methods
+-- turning a normal user to superuser
+ALTER ROLE demorole SUPERUSER;
+ALTER ROLE demorole NOSUPERUSER;
+
+-- one can also specify passwords from command line but that's not recommended, if needed then only in md5 form
+-- recommended way is to use the psql "\password" command.
+
+ALTER ROLE demorole_ro PASSWORD 'mypass';
+-- md5 format, hash generated with "select md5('mypassdemorole_ro')"
+ALTER ROLE demorole_ro PASSWORD 'md50aa307ba3b035a4c77e7417a75bf71af';
+
+ALTER DATABASE pg_features_demo OWNER TO demorole;

02_create_schema.sql

@@ -1,25 +1,32 @@
+RESET ROLE;
 /*
 Schemas in Postgres are basically "namespaces", allowing tables with same names within one DB, if schema names differ.
 By default there is always one "public" schema pre-created with every database, but for bigger applications it is usually 
 preferable to create more schemas to logically group business functionality: e.g. customer_data, product_data.
  
 Hierarchy of objects is thus such:   Cluster -> Database -> Schema -> Table
 */
-CREATE SCHEMA IF NOT EXISTS banking_demo AUTHORIZATION demorole;
+CREATE SCHEMA IF NOT EXISTS banking AUTHORIZATION demorole;     -- here we create a schema for our demo banking app
 
 /*
 When creating schemas, one also usually should define according access privileges.
 "USAGE" privilege for schemas is a privilege allowing looking at structures within schemas.
-Here we also introduce the "public" role, meaning an internal synonym for "all users" - this if you grant some rights to 
-"public", every user has it.
+NB! If you grant something to "public" role (an internal synonym for "all users"),  then every user has this grant.
 */
-GRANT USAGE ON SCHEMA banking_demo TO public;
-
+GRANT USAGE ON SCHEMA banking TO demorole_ro;   -- keeping things tight here
+                                                -- now only demorole (owner) and demorole_ro have access
 
 /*
 Postgres has the feature of DEFAULT PRIVILEGES that can be used to easily maintain very granular privilege systems.
-Here for example we declare that for all tables we create in our banking_demo schema, system will automatically grant 
+Here for example we declare that for all tables we create in our banking schema, system will automatically grant
 read rights for the "demorole_ro" role.
 */
-ALTER DEFAULT PRIVILEGES IN SCHEMA banking_demo
+SET ROLE TO demorole;
+
+ALTER DEFAULT PRIVILEGES
+    FOR ROLE demorole
+    IN SCHEMA banking
+	GRANT SELECT ON TABLES TO demorole_ro;
+ALTER DEFAULT PRIVILEGES
+    IN SCHEMA public
 	GRANT SELECT ON TABLES TO demorole_ro;

02_search_path.sql

@@ -11,12 +11,12 @@ Schemas can also be used to do sort of "API versioning" when using views or stor
 SELECT current_setting('search_path') AS default_search_path;
 
 -- currently we need to type for example something like that:
--- SELECT count(*) from banking_demo.tableX
+-- SELECT count(*) from banking.tableX
 
 -- will become active on next login or after server settings reload
-ALTER DATABASE pg_features_demo SET search_path TO banking_demo, public;
+ALTER DATABASE pg_features_demo SET search_path TO public, banking;
 -- for this session also
-SET search_path TO banking_demo, public;
+SET search_path TO public, banking;
 
--- after that we can type:
+-- after that we can for example query tables from the "banking" schema without specifying the schema explicitly:
 -- SELECT count(*) from tableX

03_make_public_schema_secure.sql

@@ -1,9 +1,20 @@
 /*
-"USAGE" for schemas allows looking at structures within schemas.
-Thus for sensitive environments it is recommended to avoid creating object in the "public" schema (namespace) or to 
-revoke "public" (all users) access like below.
+
+For sensitive environments it is recommended to avoid creating object in the "public" schema or even better to secure
+the "public" schema like below so that people could not create tables in there and look at other peoples structures.
+When still working with the public schema you would also want to set up DEFAULT PRIVILEGES that your "trusted users"
+would still get automatic access to new object in the "public" schema.
 */
+
+-- USAGE for schemas allows looking at structures within schemas, a prerequisite for looking at data
+-- additionally unprivileged users can create tables, causing IO load and danger of running out of disk space
 REVOKE USAGE ON SCHEMA public FROM public;
 
 -- Whitelist needed users later
 GRANT USAGE ON SCHEMA public TO demorole;
+GRANT USAGE ON SCHEMA public TO demorole_ro;
+
+ALTER DEFAULT PRIVILEGES
+    IN SCHEMA public
+	GRANT SELECT ON TABLES TO demorole_ro;
+

04_alter_role.sql

@@ -1,6 +1,11 @@
 -- It's possible to set global, or per user or per user/db settings. Most used such settings are search_path and statement_timeout.
 -- Changes are effective with next login.
 
-ALTER ROLE demorole IN DATABASE pg_features_demo SET search_path TO demo, public;
-ALTER ROLE demorole_ro IN DATABASE pg_features_demo SET search_path TO demo, public;
+RESET ROLE;
+
+ALTER ROLE demorole IN DATABASE pg_features_demo SET search_path TO public, banking;
+ALTER ROLE demorole_ro IN DATABASE pg_features_demo SET search_path TO public, banking;
 ALTER ROLE demorole_ro IN DATABASE pg_features_demo SET statement_timeout TO '5s';
+
+SET ROLE TO demorole;
+

05_create_table.sql

@@ -7,25 +7,26 @@ SET ROLE TO demorole;
 -- CREATE TABLEs for our super-simplified banking schema. For those more familiar with Postgres you may notice the schema is 
 -- very similar to the one used by default Postgres benchmarking tool "pgbench"
 
-CREATE TABLE banking_demo.branch(
+CREATE TABLE banking.branch(
     branch_id       int NOT NULL PRIMARY KEY,   -- using just "id" for name here is not recommended, the more explicit the better for important stuff
     balance         numeric NOT NULL DEFAULT 0
 );
 
-CREATE TABLE banking_demo.teller(
+CREATE TABLE banking.teller(
     teller_id       int NOT NULL PRIMARY KEY,
     branch_id       int NOT NULL,
     balance         numeric NOT NULL DEFAULT 0
 );
 
-CREATE TABLE banking_demo.account(
+CREATE TABLE banking.account(
     account_id      int NOT NULL PRIMARY KEY,
     branch_id       int NOT NULL,
     teller_id       int NOT NULL,
     balance         numeric NOT NULL DEFAULT 0
 );
 
-CREATE TABLE banking_demo.transaction_history(
+CREATE TABLE banking.transaction_history(
+    id              SERIAL NOT NULL,
     teller_id       int NOT NULL,
     branch_id       int NOT NULL,
     account_id      int NOT NULL,
@@ -34,39 +35,39 @@ CREATE TABLE banking_demo.transaction_history(
 );
 
 -- Generally it's also a good practice to at least minimally comment the tables and columns for complex applications
-COMMENT ON TABLE banking_demo.transaction_history IS 'A simple banking table';
-COMMENT ON COLUMN banking_demo.transaction_history.delta IS 'Change in account balance for one transaction';
+COMMENT ON TABLE banking.transaction_history IS 'A simple banking table';
+COMMENT ON COLUMN banking.transaction_history.delta IS 'Change in account balance for one transaction';
 
 -- generate 1 branch, 10 tellers for branch, 10K accounts for each teller with random balances
 
-INSERT INTO banking_demo.branch (branch_id)
+INSERT INTO banking.branch (branch_id)
     VALUES (1);
 
-INSERT INTO banking_demo.teller (teller_id, branch_id)
+INSERT INTO banking.teller (teller_id, branch_id)
     SELECT generate_series(1, 10), 1;
 
-INSERT INTO banking_demo.account (account_id, teller_id, branch_id)
+INSERT INTO banking.account (account_id, teller_id, branch_id)
     SELECT i, i % 10 + 1, 1 FROM generate_series(1, 1e5) i;
 
 
 -- Adding foreign keys and indexes
 -- (more correct would be to add them before inserting data but also inserts would be slower then)
 
-CREATE INDEX ON banking_demo.account (teller_id);
-CREATE INDEX ON banking_demo.account (branch_id);
-CREATE INDEX ON banking_demo.transaction_history (account_id);
-CREATE INDEX ON banking_demo.transaction_history (teller_id);
-CREATE INDEX ON banking_demo.transaction_history (created_on);
+CREATE INDEX ON banking.account (teller_id);
+CREATE INDEX ON banking.account (branch_id);
+CREATE INDEX ON banking.transaction_history (account_id);
+CREATE INDEX ON banking.transaction_history (teller_id);
+CREATE INDEX ON banking.transaction_history (created_on);
 
-ALTER TABLE banking_demo.teller ADD FOREIGN KEY (branch_id) REFERENCES banking_demo.branch;
-ALTER TABLE banking_demo.account ADD FOREIGN KEY (branch_id) REFERENCES banking_demo.branch;
-ALTER TABLE banking_demo.account ADD FOREIGN KEY (teller_id) REFERENCES banking_demo.teller;
-ALTER TABLE banking_demo.transaction_history ADD FOREIGN KEY (branch_id) REFERENCES banking_demo.branch;
-ALTER TABLE banking_demo.transaction_history ADD FOREIGN KEY (teller_id) REFERENCES banking_demo.teller;
-ALTER TABLE banking_demo.transaction_history ADD FOREIGN KEY (account_id) REFERENCES banking_demo.account;
+ALTER TABLE banking.teller ADD FOREIGN KEY (branch_id) REFERENCES banking.branch;
+ALTER TABLE banking.account ADD FOREIGN KEY (branch_id) REFERENCES banking.branch;
+ALTER TABLE banking.account ADD FOREIGN KEY (teller_id) REFERENCES banking.teller;
+ALTER TABLE banking.transaction_history ADD FOREIGN KEY (branch_id) REFERENCES banking.branch;
+ALTER TABLE banking.transaction_history ADD FOREIGN KEY (teller_id) REFERENCES banking.teller;
+ALTER TABLE banking.transaction_history ADD FOREIGN KEY (account_id) REFERENCES banking.account;
 
 
 -- Also when adding/changing a lot of row that will be used immediately it is benefical to explicitly force gathering 
 -- of column statistics with ANALYZE
-ANALYZE banking_demo.teller;
-ANALYZE banking_demo.account;
+ANALYZE banking.teller;
+ANALYZE banking.account;

06_create_table_options.sql

@@ -8,12 +8,12 @@ Other types of tables are:
     2) "unlogged" tables - such tables are not WAL-logged thus a lot faster to work with. Downside is that they're emptied after a crash.
 */
 
--- create a temporary copy of banking_demo.teller
+-- create a temporary copy of banking.teller
 -- NB! Note that you cannot specify a schema for temp tables
-CREATE TEMP TABLE teller_temp(LIKE banking_demo.teller EXCLUDING INDEXES);
+CREATE TEMP TABLE teller_temp(LIKE banking.teller EXCLUDING INDEXES);
 
 -- could also "auto create" a table from select (no indexes, FKs, checks, etc are transferred)
-CREATE TEMP TABLE teller_temp_2 AS SELECT * FROM banking_demo.teller WHERE false;
+CREATE TEMP TABLE teller_temp_2 AS SELECT * FROM banking.teller WHERE false;
 
 -- unlogged tables are a good option for staging tables that get a lot of updates and can be re-initialized quickly from input data
-CREATE UNLOGGED TABLE banking_demo.staging_data AS SELECT * FROM banking_demo.account;
+CREATE UNLOGGED TABLE banking.staging_data AS SELECT * FROM banking.account;

07_alter_table.sql

@@ -13,17 +13,17 @@ ALTER TABLE is mostly commonly used to:
 -- adding a new column
 -- note that here we also demonstrate that changing the structure can be performed transactionally!! (unlike in Oracle for example)
 BEGIN;
-ALTER TABLE account_unlogged ADD COLUMN extra_info TEXT;
-ALTER TABLE account_unlogged ALTER COLUMN extra_info SET DEFAULT 'hello';
+ALTER TABLE staging_data ADD COLUMN extra_info TEXT;
+ALTER TABLE staging_data ALTER COLUMN extra_info SET DEFAULT 'hello';
 COMMIT;
 -- also note that for big tables on busy DBs the above 2-step form is much preferred over below form as it won't re-write the whole table:
 -- ALTER TABLE account_unlogged ADD COLUMN extra_info TEXT DEFAULT 'hello';
 
 -- adding a simple check constraint
-ALTER TABLE account_unlogged ADD CONSTRAINT CHECK my_check CHECK (account_id > 0);
+ALTER TABLE staging_data ADD CONSTRAINT my_check CHECK (account_id > 0);
 
 -- change column data type. NB! mostly it means a full table re-write so be wary.
-ALTER TABLE account_unlogged ALTER COLUMN extra_info TYPE varchar(500);
+ALTER TABLE staging_data ALTER COLUMN extra_info TYPE varchar(500);
 
 
 /*
@@ -32,4 +32,4 @@ It tells Postgres to fill up tables only to specified percentage, so that future
 have a chance to be performed "in line" (called HOT-updates). Some "terms and conditions" apply but for certain usecases (a lot of 
 updates on un-indexed columns) huge boosts are possible. Fillfactor can be also specified similarily when creating the table.
 */
-ALTER TABLE account_unlogged SET (FILLFACTOR=80);
+ALTER TABLE staging_data SET (FILLFACTOR=80);

09_data_type_showcase.sql

@@ -1,4 +1,4 @@
-CREATE TABLE main_datatypes (
+CREATE TABLE public.main_datatypes (
     /* serials aka sequences */
     id          bigserial PRIMARY KEY,   -- serial/bigserial corresponds to int4/int8 and will just auto-attach a DEFAULT sequence
 
@@ -25,8 +25,8 @@ CREATE TABLE main_datatypes (
     /* typical auditing fields to track changes of important data*/
     created_by text NOT NULL DEFAULT current_user,
     created_on timestamptz NOT NULL DEFAULT now(),
-    last_modified_by text           -- would need a trigger to ensure it's always updated when changing data
-    last_modified_on timestamptz,   -- would need a trigger to ensure it's always updated when changing data
+    last_modified_by text,          -- would need a trigger to ensure it's always updated when changing data
+    last_modified_on timestamptz    -- would need a trigger to ensure it's always updated when changing data
 );