SECU_POSTGRES

Roles
====
les roles sont définis en même temps pour toutes les bases.
commandes sql
	CREATE ROLE name;
	DROP ROLE name;
programme externe
	createuser name
	dropuser name
	
pour visualiser les roles:
SELECT rolname FROM pg_roles;
ou bien:
\du
un superuser est créé à l'initdb. C'est le user-os qui a lançé initdb.
l'option -U précise le user. Par defaut, c'est le nom du user-os (par exemple à la connexion de psql, ou pour createuser)
l'ensemble des rôles accessibles à un user-os est déterminé par client authentication setup (ch19)

Les attributs d'un role
****************
* login privilege
Si un role a le droit de connection, c'est un user database
CREATE ROLE name LOGIN; === CREATE USER name;

* superuser status
a tous les droits. Aucune règle appliquée
CREATE ROLE name SUPERUSER; ((il faut être superuser)

* database creation
CREATE ROLE name CREATEDB

* role creation
CREATE ROLE name CREATEROLE

* password
pertinent seulement pour les méthodes d'auth qui requirent un password
CREATE ROLE name PASSWORD ’string'

beaucoup de runtime configuration settings peuvent être positionnés
ALTER ROLE myname SET enable_indexscan TO off;
ils sont activés à la prochaine connexion (inutile pour les roles qui n'ont pas de droit de connexion)
pour supprimer cette config
 ALTER ROLE myname RESET enable_indexscan;

Conseil
******
créer un superuser postgres
créer un role ayant CREATEDB et CREATEROLE qui n'est pas postgres, par exemple openbarter

privileges
=======
Pour la pluspart des objets, le propriétaire est le rôle qui a exécuté la requête de création.
Pour que d'autres rôle aient accès à l'objet, des privilèges doivent être accordés.
différents types de privilèges:
	SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER,
	CREATE, CONNECT, TEMPORARY, EXECUTE, USAGE
pour accorder un privilège:
	GRANT UPDATE ON accounts TO joe;
si à la place de joe, on met PUBLIC, le privilège est accordé à tous les rôles.
si a la place de UPDATE, on met ALL, tous les privilèges sont accordés à joe.
	REVOKE ALL ON accounts FROM PUBLIC;
Les droits de modification et de destruction sont implicitement accordés au propriétaire, et ne peuvent être modifiés sauf par lui même.

la propriété d'un objet peut être modifiée si on est superuser ou si 
le rôle est sont propriétaire et membre du rôle qui sera le nouveau propriétaire.

Appartenance à un rôle
=================
	CREATE ROLE group_name;
	GRANT group_role TO role1, ... ;
	REVOKE group_role FROM role1, ... ;
role1 peut aussi être lui même un groupe.
les appartenances circulaires sont interdites. Il n'est pas permis d'accorder l'appartenance à PUBLIC.
Les membres d'un groupe peuvent utiliser ses privilèges de deux manières:
	un membre peut faire un SET ROLE pour appartenir temporairement au groupe,
	un membre qui a l'attribut INHERIT a automatiquement les provilèges des groupes dont il est membre;
	
	CREATE ROLE joe LOGIN INHERIT;
	CREATE ROLE admin NOINHERIT;
	CREATE ROLE wheel;
	GRANT admin TO joe;
	GRANT wheel TO admin;
une session joe a ses propres privilèges, ceux d'admin mais pas ceux de wheel. 
	joe<--admin<-|-wheel
après:
	SET ROLE admin;
la session n'a que les privilèges d'admin, pas ceux de joe
après:
	SET ROLE wheel;
la session n'a que les privilèges de wheel, pas ceux de admin ni de joe
les privilèges initiaux sont restaurés par l'une des commandes:
	SET ROLE joe;
	SET ROLE NONE;
	RESET ROLE;
Une session ne peut choisir qu'un rôle dont elle est directement membre. Il faut donc passer par admin pour devenir wheel.
Les attributs de rôle  LOGIN, SUPERUSER, CREATEDB, et CREATEROLE peuvent être vus comme des privilèges spéciaux, 
mais ne sont pas hérités comme des privilèges sur des objets de la base. Il faut explicitement faire SET ROLE pour acquérir l'attribut.

Pour détruire un group-role:
	DROP ROLE group-role;
les objets appartenant a group-role doivent d'abord être réaffectés à d'autres 
et toutes les permissions accordées au group-role doivent être révoquées.
les rôles membres ne sont pas affectés si ce n'est qu'ils n'appartiennent plus au group-role.


INSTALLATION
***********

requis:
	gmake --version 			>3.76.1
	gzip
	libreadline				package readline et readline-devel
	zlib
	OpenSSL
	gnu flex et bison
	
	sur windows, visualC++ 2005

installation
	./configure
		--with-openssl
		...
	make
	make install
	
variables d'environnement:
	dans ~/.bash_profile ou /etc/profile pour affecter ts les users
	PATH=/usr/local/pgsql/bin:$PATH
	export PATH
	
démarrage:
	voir dans les sources contrib/start-scripts/linux
	
POSTGRES SSL
***********
[CH 17.8]
ssl must be enabled in postgresql.conf:
ssl = on
you can specify ciphers specifically for use by the database server, but NULL* cyphers
as NULL-SHA and NULL-MD5 are not recommended.
the server need to be restarted when it is modified.

system wide configuration file of openssl is given by the command:
openssl version -d
it is usually /usr/lib/ssl. 

1 SERVER SIDE
1.1 SERVER CERTIFICATE
In this server directory, files server.crt and server.key must exist, containing server certificate and private key respectively.
The permissions on server.key must disallow any access to world or group. Acheive this by the command:
chmod og-rwx server.key
If the certificate is signed by an intermediate certificate authority, certificates of signing authorities 
must be appended to the file server.crt up to the root authority trusted by clients.
Hence, root certificate should always be included in server.crt.

Summary of files needed:
$PGDATA/server.crt	server certificate
$PGDATA/server.key	server private key
$PGDATA/root.crt	trusted certificate authorities
$PGDATA/root.crl		certificates revoked by CA
these files are only examined at server start-up

1.2 CLIENT CERTIFICATE
To require the client to supply a trusted certificate, 
	place certificates of CA you trust in root.crt. 
	set the clientcert to 1 in pg_hba.conf. The row should be specified as hostssl
	place a CRL root.crl in the directory

example of pg_hba.conf

# TYPE  	DATABASE        USER            	CIDR-ADDRESS            METHOD
hostssl    marketdb            deposiraty             192.168.0.0/16          	cert clientcert=1

The files server.key,server.crt,root.crt,root.crl must be present.

Creating a self-signed certificate

create a privkey.pem and a certificate signing request
openssl req -new -text -out server.csr 

create the server private key
openssl rsa -in privkey.pem -out server.key
rm privkey.pem

create the self signed public key
openssl req -x509 -in server.csr -text -key server.key -out server.crt
chmod og-rwx server.key

move server.key and server.crt to the appropriate directory

2 CLIENT SIDE
[CH31]
connexion parameter:
sslmode=verify-full
	verify that the server certificate is issued by a trusted CA and that the server host name 
	matches the cn (Common Name) of the certificate of the server
	
sslcert
	file name of the client ssl certificate, by default ~/.postgresql/postgresql.crt
	
sslkey
	file name of the client secret key, by default ~/.postgresql/postgresql.key
	
sslrootcert
	file containing CA cert(s) used by client to verify server certificate, by default ~/.postgresql/root.crt
	
sslcrl
	file containing crl, by default ~/.postgresql/root.crl
	
[CH19.3.10]
User name mapping can be used to allow cn to be different from the database user name. 
the mapping is defined in pg_ident.cnf
	


