MySQL >= 8.x oder MariaDB – RegularExpression Word-Bounderies – Workaround

Ich hatte gerade ein echtes Aha-Erlebnis in Sachen Regular-Expressions. In denen bin ich sonst eigentlich recht fit, aber man lernt ja bekanntlich nie aus.

Folgende Konstrukte sind in einem SQL-Statement fehlgeschlagen, nachdem ich eine aktuelle MariaDB bzw. eine MySQL 8 Datenbank im Einsatz hatte.


[[:<:]]4711[[:>:]]

Selbst mir war diese Syntax in der Form nicht bekannt. Die beiden Pattern beziehen sich auf Word-Bounderies. Mit anderen Worten wir suchen ob in einem String die Folge 4711 enthalten ist, aber nur exakt diese, Folgen wie 47112 sollen nicht gefunden werden. Im konkreten Beispiel ging es um eine kommagetrennte Liste von Zahlen die zu durchsuchen ist. Dabei kann die 4711 aber auch am Anfang oder am Ende stehen. In MySQL 8 und höher ist der Unterstützung für diese Syntax weggefallen, aus welchem Grunde auch immer. Aber es gibt Ersatz:


[^[:word:]]4711[^[:word:]]

Auch hier suchen wir die Ziffernfolge umrandet von etwas was kein Wort ist – das kann ein Zeilenende, Zeilenanfang, oder etwas anderes als alphanumerisch + “_” sein [:word:] == [:alphanum:_].

 

Vorinitialisierter FTP-Server in Docker

Bevor hier jetzt einige gleich aufschreien für was man eine derartig krude Sache überhaupt brauchen kann, es gibt durchaus Fälle in denen etwas derartiges nützlich ist. Mir ist durchaus bewusst, dass FTP (ohne TLS) kein wirklich aktueller Standard mehr ist und auch das Protokoll mit der “out-of-band”-Regelung mit getrennten Ports etwas altbacken wirkt. Besser wäre es natürlich hier auf SFTP (welches als Basis SSH nutzt und somit direkt Verschlüsselung anbietet) zu nutzen. Zudem wurde ja auch schon mehrfach angekündigt, dass immer weniger Browser FTP nativ unterstützen wollen. Das Protokoll hat sich schlichtweg etwas überlebt, aber es ist leider in ganz vielen Bereichen immer noch im Einsatz – und genau dafür benötigte ich diese Konstellation: Für ein Projekt bei dem ich im Rahmen der Tests sicherstellen muss, dass FTP-Verbindungen bzw. die Verarbeitung von per FTP bereit gestellten Dateien wie erwartet funktionieren. Bisher habe ich mir dafür immer eine virtuelle Maschine in der Hinterhand gehalten und diese dann entsprechend hochgefahren bzw. konfiguriert. Das geht auch auf einem CI/CD-System wie Jenkins, aber schicker wäre es doch wenn man einfach ein Image starten kann (vorzugsweise in einem gekappselten  Netzwerk) und die Konfiguration und ggf. sogar schon die notwendigen Testdaten liegen fix und fertig bereit.

Insgesamt muss ich leider sagen: Diese Nuss hat mich mehr Nerven gekostet als gedacht.

<pre>FROM fauria/vsftpd

COPY ftp-custom-dir-list /tmp/
COPY ftp-user-list /etc/vsftpd/user-list
COPY init_users_and_directories.sh /tmp/
COPY vsftpd.conf /etc/vsftpd/vsftpd.conf

RUN chmod +x /tmp/init_users_and_directories.sh && mkdir -p /var/log/vsftpd/
RUN /tmp/init_users_and_directories.sh

ENTRYPOINT ["/usr/sbin/vsftpd"]
CMD ["/etc/vsftpd/vsftpd.conf"]

Hier sind einige Kleinigkeiten versteckt die man beachten muss: Das aufgerufene Skript kümmert sich letztlich während des Bauens des Images darum, dass die notwendigen Verzeichnisse angelegt werden und die Benutzerliste in eine Berkeley-DB überführt wird, damit sie später zur Authentifizierung genutzt werden kann. Das Format gilt es hierbei zu beachten: Immer abwechselnd Benutzername und Passwort in einer Zeile.

<pre>db_load -T -t hash -f /etc/vsftpd/userlist /etc/vsftpd/virtual_users.db</pre>

Es gibt noch einige Kleinigkeiten, die einem ggf. das Leben schwer machen. Zum einen ist VSFTP nicht wirklich ein gesprächiges Programm, ich habe auch mit sehr viel Suchen keine Möglichkeit gefunden in irgendeinem Log mehr als die FTP-Verbindungen zu finden, geschweige denn irgendwelche Aussagen warum es initial mit der Authentifizierung nicht so ganz klappen wollte.

Authentifizierung ist ein gutes Stichwort: Wie man hier sieht habe ich auf die Verschlüsselung der Passwörter verzichtet. Für das angestrebte Ziel einen Testserver zu haben auf dem man Dateien ablegen zum Testen ablegen kann und den man hinterher wieder wegwirft ist das gerade noch zu verschmerzen, für die Produktion ist ein deratiges Vorgehen definitiv nicht geeignet! Hier darf man sich dann aber mit den Wirren von PAM (plugable authentification module) herum schlagen, auch dieses Tool ist zumindest im Docker-Umfeld eher schweigsam und verrät sicherheitsgerichtet nicht wirklich was gerade schiefläuft.

Wer sich das von mir verwendete Basis-Image anschaut wird feststellen, dass es eigentlich auch noch diverse Parameter gibt, die man dem Container mitgeben könnte. Das habe ich allerdings lahmgelegt, denn für meinen Anwendungsfall benötige ich ja stets ein einheitliches Set an Benutzern und Verzeichnissen. Selbst wenn ich den Container beim Testen mit docker-compose hochfahren würde, bekäme ich so nicht die Kohäsion die ich mir speziell für diesen Fall wünschen würde: Einmal bauen und alles ist für den spezifischen Anwendungsfall schon vorbereitet.

Damit es mit verschlüsselten Passwörtern klappt, muss man folgende Punkte beachten:

Passwörter kann man sich mittels folgendem Befehl in Hashes umwandeln lassen:


openssl passwd -1 meintollesPasswort

Wenn man es stärker automatisieren möchte kann man sich das natürlich auch in ein Skript packen welches die Datei der User durchackert und das automatisch macht. Ganz wichtig ist aber dann auch die Anpassung der PAM-Konfiguration

<pre>#%PAM-1.0
auth   required   pam_userdb.so  db=/etc/vsftpd/virtual_users crypt=crypt
account    required   pam_userdb.so  db=/etc/vsftpd/virtual_users crypt=crypt
session    required   pam_loginuid.so

Man muss PAM hier mitteilen, dass die Passwörter in verschlüsselter Form vorliegen. Nicht wundern, dass ich oben nicht mit crypt als Methode im Zusammenhang mit openssl gearbeitet habe: Crypt ist dort die Urform des Hash-Algorithmus für Passwörter. Aus historischen Gründen dürfen Passwörter dort nur 8 Zeichen lang werden. Hier sei nochmals darauf hingewiesen, dies betrifft nur die Art und Weise wie die Passwörter auf dem Server gespeichert werden, die Übertragung bei FTP erfolgt weiterhin ohne Veschlüsselung – hier muss man ggf. mit VPN oder anderen Mechanismen nachhelfen (oder eben gleich SFTP einsetzen).

Wer genau aufgepasst hat, wird feststellen, dass in der PAM-Konfiguration scheinbar ein Fehler ist (und dieser hat mich lange beschäftigt). Es ist aber richtig: die Datei muss auf .db enden, die Referenz für pam_userdb.so muss aber ohne dieses Suffix erfolgen. Wer auch immer sich das ausgedacht hat – wirklich gut dokumentiert ist es auf keinen Fall.