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

["rene hankel" <rene(dot)hankel(at)avt-verkehrstechnik(dot)de>]

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