Re: Insert-problem bei zugriff mittels login- und gruppenrole

> 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).

aaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhh verdammt!
du bist der held!!! habe dem besitzer seine urspruenglichen rechte
gegeben und siehe da...funzt. :( :)

ich idi dachte mir naemlich, warum sollte der owner was lesen koennen?
ist doch unwichtig! haette nie gedacht das es daran haengt! verdammt,
verdammt, verdammt und wer ist schuld? ich!

> 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.

jupp absolut klar und danke fuer deinen bleistift ;-)