readme index

README.md

@@ -1,9 +1,22 @@
+
 # PostgreSQL expiration date management functions
 
+## Table of Contents
+
+1. [TOC](README.md#postgresql-expiration-date-management-functions)
+	1. [Description](README.md#description)
+	2. [Instructions](README.md#instructions)
+	3. [Helper script](README.md#helper-script)
+	4. [RDS considerations](README.md#rds-considerations)
+	5. [Security considerations](README.md#security-considerations)
+
 ## Description
 
 This project tries to find a way to allow users the management of the `VALID UNTIL` expiration clause by themself.
-All without granting `super` permissions and having a histoc of changes on a _pseudo-audit_ table
+Everyghin without granting `super` permissions and having a histoc of changes on a _pseudo-audit_ table.
+
+You can easly combine this functions with the [passwordcheck extra](https://github.com/michaelpq/pg_plugins/tree/main/passwordcheck_extra) extension, the regex inside `dba.change_valid_until` match the _default_ requirements in the extension for special characters and you can change the variable `_min_password_length` to match your requirements (in the case you changed it, of course).
+
 
 | :warning: WARNING          |
 |:---------------------------|
@@ -13,6 +26,11 @@ All without granting `super` permissions and having a histoc of changes on a _ps
 ## Instructions
 
 ### First deploy
+
+Modify `passchanger.sql` according your needings:
+  * Change `_min_password_length` on `change_my_password` function
+  * Change `_password_lifetime` on `change_valid_until` function
+
 Deploy `passchanger.sql` on the desired cluster/database.
 
 It will:
@@ -23,6 +41,17 @@ It will:
   * Create the 2 needed functions and grant permissions on them to `dba`
 
 
+### Updates
+
+Just execute the `CREATE OR REPLACE FUNCTION` part of the `passchanger.sql` file.
+
+| :warning: WARNING          |
+|:---------------------------|
+| Amazon RDS has some notes at the end... |
+| :warning: WARNING          |
+
+
+
 ### Allowing users to use that functions
 Take the file `grants_to_grant.sql` and modify the username _dodger_ so it match the username that should have the permissions.
 Execute the grants on the cluster/database you have deployed `passchanger.sql`
@@ -52,10 +81,22 @@ select dba.change_my_password('<Wl}TxqRPBQaV_N<rU#A') ;
 
 ## RDS considerations
 
-As Amazon has modified Postgresql so you don't have access as a *real* superuser, the _dangerous_ function
+As Amazon has modified Postgresql so you don't have access as a *real* superuser and the _dangerous_ function
 `change_valid_until` should run as the owner of the database (the user created when you deploy the database through AWS)
 
-There's a `passchanger_rds.sqlp` file which should be used instead of the normal one.
+There's a `passchanger_rds.sql` file which should be used instead of the normal one.
+
+For updates you should change the owner of the `change_valid_until` to the database _owner_:
+```
+ALTER FUNCTION dba.change_valid_until(text) OWNER TO _DATABASEOWNER;
+```
+Modify `_DATABASEOWNER` according your admin username...
+
+
+## Security considerations
+
+  * Non-RDS `change_valid_until` function does not uses `ALTER USER` to modify `VALID UNTIL`, it makes an `update pg_catalog.pg_authid set rolvaliduntil` instead, so the `dba` user has only grant over that table/column instead of granting additional permissions to him.
+  * RDS `change_valid_until` should run as the database owner, is the only way to make this work as you can't access `pg_catalog.pg_authid` on rds, it uses `ALTER USER ... VALID UNTIL` instead.