Re: ssl

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Olaf Radicke *EXTERN*" <olaf_rad(at)gmx(dot)de>, <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: Re: ssl
Date: 2007-09-07 09:03:30
Message-ID: D960CB61B694CF459DCFB4B0128514C22FB6B1@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Olaf Radicke schrieb:
> Das Rechte System bei Postgresql finde ich nicht immer schlüssig.

Ich verstehe, daß Sie unglücklich sind, aber die meisten
dieser Dinge haben einen guten Grund. Wenn man die Architektur
versteht, werden sie klar. Wenn man die Architektur nicht
versteht, hat man immer Probleme bei der Administration.

> Wenn ich kein ssl benutzen will, benutze ich es in der
> pg_hba.conf einfach nicht. Warum sollte ich auf die Idee
> kommen es in der postgresql.conf _noch_mal_ abzuschalten?

In der postgresql.conf stellt man ein, ob PostgreSQL überhaupt
SSL verwenden soll oder nicht. Das hat noch nichts mit
Benutzerverwaltung zu tun.
Wenn SSL eingeschaltet ist, weigert sich der Server zu starten,
wenn er kein richtiges Zertifikat + Key findet. Das ist schon gut
so, daß es da nicht nur einen Schrei im Log gibt, den würde man
zu leicht ignorieren.
Andererseits, wenn jemand kein SSL will, soll der Server
trotzdem starten.
Wie macht man das ---> mit einem config-Parameter

In der pg_hba.conf findet die Autorisierung statt, also wer
was von wo aus wie darf. Vielleicht möchte ich generell nur
User über SSL hereinlassen, aber für eine Datenbank eine
Ausnahme machen? Wir haben das z.B. gebraucht.

> Ich finde die Doppelte Benutzerverwaltung schon
> verwirrend. Das man mit seinem DB-Account (wenn man die
> Rechte hat) einen neuen DB-User anlegen kann, es aber einem
> garnichts nützt, solange dieser nicht in der pg_hba.conf
> frei geschaltet wird.

Da muß ich zustimmen, das ist etwas mühsam.
Ich glaube, das hat historische Gründe.

In 8.2 kann man sich die Sache erleichtern:
Man schreibt einmal eine pg_hba.conf, die Generelles
festlegt (z.B.: dieser Cluster akzeptiert nur SSL-Verbindungen).
Durch das neue CONNECT-Recht auf Datenbanken kann man dann
mit einem GRANT festlegen, wer auf welche Datenbank
darf.

> Oder das ich keinen Einfluss als DB-Besitzer habe, auf
> welche wege sich die von mir angelegten Benutzer
> authentifizieren müssen. Und umgekehrt, das der "Master of
> pg_hba.conf" allen das Wasser abdrehen darf.

Wieder ein Architekturverständnisproblem.
Der "Master of pg_hba.conf" ist der Clusteradministrator.
User sind nicht Objekte auf Datenbankebene, sondern auf
Clusterebene.

"DB-Besitzer" und "Benutzeradministrator" sind also verschiedene
Aufgaben auf verscheidenen Ebenen in PostgreSQL.

Vielleicht klingt es so sinnvoller:

- Der "Clusteradministrator" legt fest, von wo und wie
überhaupt auf den Cluster zugegriffen werden kann. Er
bestimmt die Parameter in postgresql.conf. Er hat shell
access am Datenbank-Rechner.
Klar kann der allen das Wasser abdrehen, er kann auch
den Server stoppen.

- Der "Benutzeradministrator" hat das CREATEROLE-Privileg.
Er kann User anlegen und ändern.

- Der "Datenbankadministrator" besitzt die Datenbank.
Er kann Usern das CONNECT-Recht auf seine Datenbank geben.

Im Lichte dieser (eben von mir erfundenen) Nomenklatur
erscheint es natürlich seltsam, daß in der pg_hba.conf
einzelne auf einzelne Datenbanken berechtigt werden können.
Aber - wie oben erwähnt - darauf kann man in 8.2 verzichten.

Klar ist das alles nicht ganz einfach, aber das ist meist
der Preis, den man für Vielseitigkeit zahlt.
Es gibt einfachere Datenbanksysteme, die auch nicht schlecht
sind, wenn man "nur schnell einmal eine Datenbank" braucht.

Um mit einem alten Vorurteil ins Gericht zu gehen,
MySQL ist auch nicht einfacher.

Liebe Grüße,
Laurenz Albe

In response to

  • Re: ssl at 2007-09-07 07:52:29 from Olaf Radicke

Responses

  • Re: ssl at 2007-09-07 09:32:45 from Olaf Radicke

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Olaf Radicke 2007-09-07 09:32:45 Re: ssl
Previous Message Christian Voelker 2007-09-07 08:28:18 Re: ssl