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

Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.

Wie man der Kommunikation zu den Konqueror-Bugs

http://bugs.kde.org/show_bug.cgi?id=150070 und http://bugs.kde.org/show_bug.cgi?id=149957

entnehmen kann, gibt es seit ein paar (Entwicklungs-) Versionen wohl tatsächlich Schwierigkeiten bei der Interpretation von HTTP Header Direktiven. Es handelt sich dann also nicht um ein OX5 spezifisches Problem des Browsers Konqueror.

Die KDE-Entwickler arbeiten anscheinend daran – das ist beruhigend, obwohl man sich natürlich fragt, wie denn die Tests aussehen, wenn in einen so wichtigen Bereich eines Browsers eingegriffen wurde. Auf der anderen Seite führt aber auch nicht jeder Benutzer mit so hoher Frequenz wie ich ein Update der KDE Umgebung durch.

Betrachten wir das Ganze also mal als Test, wie denn die Opensource Gemeinde mit so einem Problemchen umgeht. Ich bin jedenfalls gespannt, ob und in welcher der nächsten Versionen der von SUSE publizierten KDE rpms dieser Fehler behoben sein wird.

Ergänzung:
Mir ist bei der Analyse des HTTP-Datenverkehrs zwischen OX-Server und Browser (mittels Wireshark) aufgefallen, dass die OX-Leute für den Redirect im Login-Prozess eine “REFRESH”-Direktive im HTTP-Header benutzen. Das ist insofern bemerkenswert, als dies kein HTTP 1.1-Standard ist, wenngleich diese Direktive von Firefox, IE und Opera unterstützt wird. Bis zur Version 3.5.7-64.1 wohl eben auch von Konqueror. Nur danach halt leider nicht mehr!

Eine Lehre, die sich an diesem Beispiel erneut bestätigt, ist die Folgende:

Gerade beim produktiven Einsatz von Opensource muss jedes Update des Desktops vor dem Produktiv-Einsatz gründlich auf die Funktionstüchtigkeit der Standard-Arbeitsabläufe hin getestet werden. Es wird keineswegs alles besser, wenn ein neues (Zwischen-) Release auf den Markt kommt.