Re: Insert-problem bei zugriff mittels login-

--On Donnerstag, Juni 01, 2006 12:23:44 +0200 rene hankel
<rene(dot)hankel(at)avt-verkehrstechnik(dot)de> wrote:

> ich muss zugeben das ich langsam aber sicher, absolut keine ahnung mehr
> habe wo ich suchen soll.
> ich habe mir auch die tabellenrechte mit \dp in psql angesehen - alles
> normal.
>
> ich meine die abfrage, obwohl sie vom system kommen muss(von michse ist
> sie nicht ;-))
> ist ja logisch.
>> SELECT 1 FROM ONLY "anlagen"."tbl_anlagentyp" x WHERE "id" = $1 FOR SHARE
> OF x

Ich habe den Einstieg in diesen Thread irgendwie verpasst, aber ich vermute
den
Fehler hier:

--------------8<------------------------------------------------------------------------
CREATE TABLE sonstiges.tbl_favoriten
(
-- Vererbt: erstellt_am timestamp DEFAULT ('now'::text)::timestamp(6)
without time zone,
-- Vererbt: erstellt_benutzer_id int4 DEFAULT 0,
-- Vererbt: aenderung_am timestamp,
-- Vererbt: aenderung_benutzer_id int4 DEFAULT 0,
-- Vererbt: geloescht_am timestamp,
-- Vererbt: geloescht_benutzer_id int4 DEFAULT 0,
-- Vererbt: geloescht bool DEFAULT false,
id int8 NOT NULL DEFAULT
nextval(('sonstiges.seq__tbl_favoriten__id'::text)::regclass), -- primarykey
anlage_id int8 NOT NULL, -- foreignkey -> tbl_anlage.id
benutzer_id int8 NOT NULL, -- foreignkey -> tbl_benutzer.id
CONSTRAINT pkey__tbl_favoriten__id PRIMARY KEY (id),
CONSTRAINT fkey__tbl_favoriten__anlage_id FOREIGN KEY (anlage_id)
REFERENCES anlagen.tbl_anlage (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fkey__tbl_favoriten__benutzer_id FOREIGN KEY (benutzer_id)
REFERENCES benutzer.tbl_benutzer (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
) INHERITS (virtual.tbl_tupelaenderung)
WITHOUT OIDS;

ALTER TABLE sonstiges.tbl_favoriten OWNER TO usr_dbavt_admin;
--------------8<------------------------------------------------------------------------

Der neue Besitzer der Tabelle tbl_favoriten hat keine Leseberechtigung auf
tbl_anlage, was notwendig ist, um den Foreign Key Check auszuführen
(FK-Checks
sind RI-Trigger die im Context des Tabellen-Owners ausgeführt werden).

Man kann dies aber nur schwer nachvollziehen, bei mir passiert's nur in
dieser Reihenfolge
(wenn das REVOKE für die Rolle test ganz unten steht):

CREATE SCHEMA bernd;
CREATE TABLE A(id INTEGER NOT NULL PRIMARY KEY);
CREATE TABLE B(id INTEGER NOT NULL PRIMARY KEY, name
TEXT NOT NULL, FOREIGN KEY(id) REFERENCES A(id) MATCH SIMPLE ON UPDATE
RESTRICT ON DELETE RESTRICT);

REVOKE ALL ON a FROM bhe;
REVOKE ALL ON b FROM bhe;
GRANT SELECT ON a to bhe;

GRANT SELECT,INSERT,DELETE ON b to bhe;
ALTER TABLE A OWNER TO test;

INSERT INTO A VALUES (1);
INSERT INTO A VALUES (2);
INSERT INTO A VALUES (3);
INSERT INTO A VALUES (4);
GRANT USAGE on SCHEMA bernd TO bhe;

GRANT ALL on SCHEMA bernd TO bhe;
GRANT ALL ON SCHEMA bernd to test;
REVOKE ALL ON a FROM test;

SET ROLE bhe;
INSERT INTO bernd.b VALUES (2, '');

ERROR: permission denied for relation a
CONTEXT: SQL statement "SELECT 1 FROM ONLY "bernd"."a" x WHERE "id" = $1
FOR SHARE OF x"

Da ich grade zu müde bin, mir das genauer anzusehen, verschiebe ich das auf
morgen. Es
sollte aber nun hoffentlich klar sein, wo das Problem liegt.

--
Thanks

Bernd