PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 10/05/2015 20:01:30

changement d'utilisateur courant dans la suppression en cascade

Salut
Je constate un problème avec CURRENT_USER lors d'une suppression en cascade.
La situation...( version 9.4.1)
1-->_______
Je me connecte avec le compte postgres
Création de deux tables liées avec suppression en cascade...

CREATE TABLE ta
(
  ida integer NOT NULL,
  v character varying,
  CONSTRAINT ta_pkey PRIMARY KEY (ida)
)

CREATE TABLE tb
(
  idb integer NOT NULL,
  ida integer,
  v character varying,
  CONSTRAINT tb_pkey PRIMARY KEY (idb),
  CONSTRAINT tb_ida_fkey FOREIGN KEY (ida)
      REFERENCES ta (ida) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)

La table qui enregistre l'historique de CURRENT_USER

CREATE TABLE th
(
  v character varying,
  idh serial NOT NULL,
  CONSTRAINT th_pkey PRIMARY KEY (idh)
)

Les triggers

CREATE OR REPLACE FUNCTION huser() RETURNS trigger AS
$$
begin
	insert into th(v) values(current_user);
	return old;
end
$$
  LANGUAGE plpgsql
  
 CREATE TRIGGER huser
 BEFORE DELETE
 ON ta
 FOR EACH ROW
 EXECUTE PROCEDURE huser();
  
 CREATE TRIGGER huser
 BEFORE DELETE
 ON tb
 FOR EACH ROW
 EXECUTE PROCEDURE huser();
 

Les données

INSERT INTO ta(ida, v) VALUES (1, 'A'), (2, 'B');
INSERT INTO tb(idb, ida, v) VALUES (1, 1, 'Aa'), (2, 1, 'Ab'), (3,2, 'Ba'), (4, 2, 'Bb');

2-->___________
Je me connecte avec un autre compte

La suppression dans ta (sera fait avec le nouveau compte) qui provoquera une suppression en cascade (avec le compte postgres!)

delete from ta where ida=1;

Le contenu de l'historique de CURRENT_USER

select * from th;

"vaillants"
"postgres"
"postgres"

Alors, la question: est ce un comportement normal?
Je voulais mettre ne place un mécanisme de contrôle de modification et de suppression (vous ne supprimer ou modifier que si vous êtes propriétaire ou administrateur). Mais ce comportement de PostgreSQL est un frein.
@+

Dernière modification par alassanediakite (10/05/2015 20:02:16)

Hors ligne

#2 12/05/2015 07:42:17

gleu
Administrateur

Re : changement d'utilisateur courant dans la suppression en cascade

Oui, c'est un comportement normal. La vérification et la suppression des données référencées sont effectuées par l'utilisateur propriétaire de la table.


Guillaume.

Hors ligne

#3 12/05/2015 13:02:01

Re : changement d'utilisateur courant dans la suppression en cascade

Salut et grand merci de l'info.
Mais est ce vraiment bien que PostgreSQL permet à un utilisateur (ayant droit de suppression sur ta et non sur tb) arrive quand même à supprimer des lignes dans tb?
Imaginons un chef GRH ayant le droit de suppression sur la table des ouvriers et non sur celle des pointages.
Il veut se débarrasser d'un mauvais ouvrier qui (supposons le, a déjà des pointages), imaginez la tête du comptable à la suite.
@+

Dernière modification par alassanediakite (12/05/2015 13:16:11)

Hors ligne

#4 12/05/2015 16:54:01

dverite
Membre

Re : changement d'utilisateur courant dans la suppression en cascade

Pour logger le nom d'utilisateur dans le trigger sur la table secondaire, il faudrait utiliser session_user plutôt que current_user.


Pour le problème du droit d'effaçement, il y a une contradiction entre la déclaration "ON DELETE CASCADE" d'une table à l'autre et le fait qu'un utilisateur n'ait le droit de DELETE que d'un côté de la relation.

Postgres résoud implicitement le problème en faisant systématiquement le DELETE dans l'autre table avec les droits du possesseur, prenant d'une certaine manière le parti que la déclaration "ON DELETE CASCADE" est prioritaire par rapport aux GRANT sur l'autre table.

Si une application estime le contraire, elle ne doit pas utiliser "ON DELETE CASCADE" et gérer elle-même l'intégrité référentielle dans les suppressions.

Hors ligne

#5 13/05/2015 19:53:46

Re : changement d'utilisateur courant dans la suppression en cascade

Salut
Merci de l'info, avec session_user cela marche.
@+

Hors ligne

Pied de page des forums