Probleme mit default-Privileges

Hallo an alle,
ich arbeite seit einigen Tagen mit PG und habe ein (vermutlich grundsätzliches) Problem mit dem Berechtigungssystem, dass ich allein nicht lösen kann.

Gegeben sei ein PostgreSQL 9.1.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit
und auf einer Win7 Client-Maschine das Programm pgadmin 1.14.2

Es ist die initiale Login-Role postgres und eine weitere Login-Role “a” vorhanden.
Die Login-Role a ist mit folgendem Statement vom User postgres mit dem Werkzeug psql unter Linux erzeugt worden:
CREATE ROLE a LOGIN PASSWORD ‘abc’ NOSUPERUSER NOINHERIT CREATEDB NOCREATEROLE NOREPLICATION;

Da die zeitliche Abfolge der Aktionen relevant ist und die Aufgaben wechselnd vom Administrator unter Linux und von mir unter Windows ausgeführt werden, beginnen die einzelnen Aktionen mit dem Wort “Stufe” und enden mit “–Ende von Stufe”

–Stufe1
Der Server enthält mehrere Tablespaces mit jeweils dem Eigentümer a
Eigenschaften dieser Tablespaces
Eigentümer a
ACL {a=C/a}
In einem dieser Tabelspaces ist eine Datenbank “daba”
Eigenschaften von daba:
Eigentümer a
ACL {=Tc/a,a=CTc/a}
Standard Tabellen ACL {postgres=arwdDxt/postgres}
Standard Sequence ACL {postgres=rwU/postgres}
Standard Functions ACL {=X/postgres,postgres=X/postgres}

Die DB und die Tablespaces wurden unter Linux mit psql von einem Administrator erzeugt
die DB enthält keine DB-Objekte!
–Ende von Stufe1

– Stufe2
Nun wird vom Windows-client eine Group-Role “gruppe” erzeugt.
Die role wird mit mit dem Login postgres angelegt.
CREATE ROLE gruppe
NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

die Gruppe wird mit Hilfe von einigen Statements in die Datenbank daba eingetragen.
Die Statements werden ebenfalls mit der Login-Role postgres ausgeführt.

GRANT CONNECT, TEMPORARY ON DATABASE “daba” TO public;
GRANT ALL ON DATABASE “daba” TO gruppe ;
GRANT ALL ON SCHEMA PUBLIC TO gruppe ;

ALTER DEFAULT PRIVILEGES GRANT INSERT, SELECT, UPDATE, DELETE,
TRUNCATE, REFERENCES, TRIGGER ON TABLES TO gruppe;

ALTER DEFAULT PRIVILEGES GRANT SELECT, UPDATE, USAGE ON SEQUENCES TO gruppe;

ALTER DEFAULT PRIVILEGES GRANT EXECUTE ON FUNCTIONS TO gruppe;

ALTER DEFAULT PRIVILEGES IN SCHEMA PUBLIC GRANT INSERT, SELECT, UPDATE,
DELETE, TRUNCATE, REFERENCES, TRIGGER ON TABLES TO gruppe;

ALTER DEFAULT PRIVILEGES IN SCHEMA PUBLIC GRANT SELECT, UPDATE, USAGE ON SEQUENCES
TO gruppe;

ALTER DEFAULT PRIVILEGES in SCHEMA PUBLIC GRANT EXECUTE ON FUNCTIONS TO gruppe;

GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER
ON ALL TABLES IN SCHEMA PUBLIC TO gruppe;

GRANT SELECT, UPDATE, USAGE ON ALL SEQUENCES IN SCHEMA PUBLIC TO gruppe;

GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA PUBLIC TO gruppe;

die Eigenschaften sehen jetzt so aus:
Eigenschaften von daba:
Eigentümer a
ACL {=Tc/a,a=CTc/a,gruppe=CTc/a }
Standard Tabellen ACL {postgres=arwdDxt/postgres, gruppe=arwdDxt/postgres}
Standard Sequence ACL {postgres=rwU/postgres, gruppe=rwU/postgres}
Standard Functions ACL {=X/postgres,postgres=X/postgres, gruppe=X/postgres}

Nun wird ebenfalls mit der Login-Role postgres ein realer Account eingerichtet:
CREATE ROLE benutzer LOGIN password ‘abc’
NOSUPERUSER NOINHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
ALTER ROLE benutzer SET role=‘gruppe’;
GRANT gruppe TO benutzer;
–Ende von Stufe3

–Stufe4
nachdem das alles passiert ist, werden mit der Login-Rolle a diverse DB-Objekte (Tabellen , sequences etc) erzeugt
(durch einen Administrator unter Linux).

musterhaftes Statement:
create table tab_1 (f1 int);
ALTER TABLE tab_1
OWNER TO a;
GRANT ALL ON TABLE tab_1 TO a;

Alle Tabellen haben folgende Eigenschaften:
Owner a
ACL leer(!)
tablespace: default-Tablespace von daba

–Ende von Stufe4

–Stufe5
Es erfolgt vom Windows client aus, ein Login mit der Login-Role benutzer in der datebank daba.
Und es wird versucht zu arbeiten…
–Ende von Stufe5

Meine Erwartungshaltung ist eigentlich, dass die Login-role benutzer bis auf Droppen kompletten Zugriff auf die Objekte von Daba hat.
Das ist aber nicht so. Ich erhalte statt dessen die Fehlermeldung “access denied…”


nun meine Fragen:

  1. Wieso kann die Login-Rolle benutzer nicht an die Tabellen ran?
  2. Warum ist der ACL-Eintrag der Tabellen leer, obwohl ich die Default-Privileges der DB gesetzt habe (STUFE4)?
  3. Ist meine Vorstellung korrekt, dass eine vom Superuser erzeugte Gruppe die DB-Objekte eines
    anderen Logins erreichen kann?
  4. was ist die Bedeutung von INHERIT bzw. NOINHERIT beim Einrichten einer ROLE?
    (kann es dazu kommen, dass Eigenschaften vom CREATOR “vererbt” werden?)

Über eine Antwort würde ich mich freuen
Kurt