Open-Xchange – Login des Datenbankusers “openexchange” mittels psql?

Heute wurde ich von einem User gefragt, wieso er sich auf einem OX 5 Server nicht direkt als Datenbankuser “openexchange” auf der Postgres-Datenbank mit Hilfe von “psql” einloggen könne.

Dies ist zunächst etwas überraschend, weil in jeder Installationsanleitung zum OX-Server erwähnt wird, dass im Rahmen der Installation unter Postgres die Standarddatenbank “openexchange” angelegt und dem Owner “openexchange” zugeordnet wird.

Die OX 5 Installation war im Fall des Kollegen allerdings über eine SLOX Migration auf einen SLES 9 Server durchgeführt worden. Ein Blick in die hinterlassenen Konfigurationsdateien lohnt sich für ein tiefergehendes Verständnis der Berechtigungsmechanismen, mit denen die OX-Prozesse mit der Datenbank interagieren. Schreiten wir also zur Tat:

Zunächst klären wir die Verhältnisse auf der Postgres-Datenbank. Ein kurzer Blick als Datenbank-Superuser “postgres” mittels

oxserver:~ # su postgres
oxserver:~ # psql openexchange

openexchange-> \du
List of database users
User name | User ID | Attributes
————–+———+—————————-
openexchange | 100 |
postgres | 1 | superuser, create database
(2 rows)

openexchange-> \l
List of databases
Name | Owner | Encoding
————–+————–+———–
openexchange | openexchange | UNICODE
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
(3 rows)

zeigt, dass der Datenbankuser “openexchange” wirklich der Owner der Datenbank “openexchange” ist. Versuchte man allerdings, sich als Datenbankuser “openexchange” mit der Datenbank zu verbinden, so erhielt man folgende Meldung:

oxserver:~ # psql -U openexchange
psql: FATAL: »IDENT«-Authentifizierung für Benutzer »openexchange« fehlgeschlagen

Dies entspricht dem Befund des Kollegen:
Mittels des Datenbankusers “openexchange” führt kein Weg per “psql” in die Datenbank “openexchange”. Noch mehr wundert man sich, wenn man kontrolliert, wie die OX Server bzgl. des Zugriffs auf die Datenbank konfiguriert ist:
Hierzu öffnet man die Datei “/opt/openexchange/etc/groupware/server.conf” und verifiziert folgende Einträge:

# Database Connection Parameter
NAS_CON_CLASS_NAME: jdbc:postgresql://localhost/openexchange
NAS_CON_USER: openexchange
NAS_CON_PASS: “Your_Password”
NAS_CON_DRIVER: org.postgresql.Driver

Auch hier erkennt man, dass es tatsächlich der User “openexchange” ist, der vom OX-System für den Datenbankzugriff verwendet wird. Und aus der tägliche Praxis weiß man, dass man ja auf dem OX-Server erfolgreich arbeiten kann. Wieso also gelingt der direkte Zugriff mittels psql unter Verwendung des Users “openexchange” nicht?

Des Rätsels Lösung liegt in einer Einstellung, die der OX-Installer beim Einrichten des OX-Servers aus Sicherheitsgründen vornimmt:
Ausschlaggebend für die Verbindungsmöglichkeiten zu einem Postgres-Datenbankserver sind u.a. die Einstellungen in der Datei “pg_hba.conf”. Diese findet man je nach Installation unter “/usr/local/pgsql/data/” oder nach der SLOX -> SLES 9 Migration im Verzeichnis “/var/lob/pgsql/data”. Typisch ist dort etwa der Eintrag

#modified by oxinstaller
#local openexchange openexchange trust
host all all 127.0.0.1 255.255.255.255 password
host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff password
local all all ident sameuser

Hierdurch erklärt sich endlich der Befund: Der erste Eintrag, der mit “local” beginnt, ist auskommentiert! Dieser Eintrag würde es allerdings jedem User, der über einen Account auf dem Server mit der Postgres-Datenbank verfügt und vorgibt, der Datenbankuser “openexchange” zu sein, erlauben, sich auf die Datenbank einzuloggen (psql -U
openexchange). Ausprobieren kann man dies, indem man den Eintrag aktiviert, postgres neu startet (rcpostgres restart) und dann den genannten psql-Befehl (erfolgreich!) absetzt.

Ein solches Systemverhalten will in der Regel aber eigentlich niemand riskieren, und deshalb ist es gut, dass der Eintrag auskommentiert ist! Diesen Zustand sollte man also wieder herbeiführen.

Der zweite und der dritte Eintrag sorgen dafür, dass Programme sich lokal, aber im Sinne einer IPV4 bzw. IPV6 Verbindung auf die Datenbank einlogen können. Hierfür muss nun jedoch das Passwort für den Datenbankuser “openexchange” bekannt sein. Als User root oder postgres kann man den Zugang über das Loopback-Device nun dadurch überprüfen, dass man folgenden Befehl an der Konsole eingibt:

oxsserver:~ # psql -h 127.0.0.1 openexchange -U openexchange
Password:
Welcome to psql 7.4.17, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

openexchange=>

Hierdurch erklärt sich übrigens, warum die Programme des OX-Servers mit den Einstellungen in der Datei “/opt/openexchange/etc/groupware/server.conf” erfolgreich ihre Arbeit in der Datenbank verrichten können. (Sicherheitshinweis: Gestandene Postgres-Administratoren sollten allerdings auf die Nichtverschlüsselung des Passwortes in der Datenbank ein wenig allergisch reagieren und dieses Defizit beheben. Näheres findet man in den Postgres Manuals. )

Der allerletzte Eintrag ließe einen Login auf die Bank zu, wenn man als Datenbankbenutzer den gleichen Namen aufweist wie als Betriebssystembenutzer. Dies ist zwar für Postgres der Fall, nicht aber für den Datenbankuser “openexchange”: Ein entsprechender User-Account ist aus Sicherheitsgründen gar nicht angelegt.

Keiner der aktiven Einträge lässt also einen direkten Zugriff auf die Datenbank zu. Der zweite Eintrag verlangt den Umweg über das Loopback-Device, den die OX-Programme offenbar nehmen. Der dritte Eintrag führt jedoch zur oben erwähnten Fehlermeldung.

Nachdem wir das Verhalten nun verstehen, geben wir uns damit zufrieden, dass wir zu Verwaltungs- oder Recherchezwecken ja immer noch über den Datenbankuser “postgres” aktiv werden können, wenn einem die OX-Oberfläche nicht genug Möglichkeiten bietet. Zudem könnte man sich einen weiteren Datenbankuser für seine spezifischen Zwecke einrichten oder einrichten lassen – für Recherchezwecke etwa nur mit lesendem Zugriff.

————————–
Sicherheitshinweis:
————————–
Findet man in der Datei “/opt/openexchange/etc/groupware/server.conf” übrigens den Eintrag

NAS_CON_PASS: “secret”

so hat man die Migrationsanleitung vermutlich zu wörtlich genommen und wie dort angegeben das Passwort “secret” für den DB-User “openexchange” bei der ursprünglichen OX-Installatiion auf dem SLES Server angegeben. Da man hierdurch ein potentielles Sicherheitsproblem heraufbeschworen hat, sollte man das Passwort für “openexchange” umgehend ändern. Hierzu verbindet man sich mit der Datenbank (z.B. als Superuser “postgres”) und benutzt am psql-Prompt den Befehl

> ALTER USER openexchange WITH PASSWORD ‘new-password’

um das Password abzuändern. natürlich ist new_password durch das neue gewählte Passwort zu ersetzen. Danach korrigiert man auch den Parameter NAS_CON_PASS in der Datei “/opt/openexchange/etc/groupware/server.conf” entsprechend ab:

NAS_CON_PASS: “new_password”.