Merged documentation

This commit is contained in:
dodger 2022-05-09 18:05:15 +02:00
parent 2f364bce8a
commit 3d8b1bd3d9
Signed by: dodger
GPG Key ID: F6701F6CB4D1C826
2 changed files with 12 additions and 43 deletions

View File

@ -7,7 +7,7 @@ All without granting `super` permissions and having a histoc of changes on a _ps
| :warning: WARNING |
|:---------------------------|
| Amazon RDS has its own instructions on README_rds.md |
| Amazon RDS has some notes at the end... |
| :warning: WARNING |
## Instructions
@ -48,3 +48,14 @@ dodger@ciberterminal.net $ bash password_creator.sh
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
`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.

View File

@ -1,42 +0,0 @@
# PostgreSQL expiration date management functions
## 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
## PRE-requisites
As Amazon has modified Postgresql so you don't have access as a *real* superuser, the _dangerous_ function
`change_valid_until` should run as the owner of the database (the user created when you deploy the database through AWS)
## Instructions
### First deploy
Deploy `passchanger_rds.sql` on the desired cluster/database.
It will:
* create a `dba` schema
* create a `dba` role
* create the `pwdhistory` table for audit purpouses
* Grant the minimum permissions for this new role so the whole thing works
* Create the 2 needed functions and grant permissions on them to `dba`
### 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`
### Changing password & extending expiration date
The user should just execute:
```
select dba.change_my_password('YOUR_NEW_GENERATED_PASSWORD_NOT_THIS_ONE') ;
```
## Helper script
See README.md