Vous n'êtes pas identifié(e).
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
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
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
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.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Salut
Merci de l'info, avec session_user cela marche.
@+
Hors ligne