> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. --- Ich gehe mal davon aus, dass Du nicht die Möglichkeit meinst, den MySQL/MariaDB-Benutzer und dessen Passwort in einer php.ini bzw. .user.ini zu verewigen: ~~~INI mysqli.default_user = ; Default password for mysqli_connect() (doesn't apply in safe mode). ; *Any* user with PHP access can run 'echo get_cfg_var("mysqli.default_pw") ; https://php.net/mysqli.default-pw mysqli.default_pw = ~~~ Das ist aber sicherer als in Skripten unterhalb von Document-Root. --- Das kann (eigentlich, jenseits von Skript-Konstruktionen, bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird, siehe oben) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. --- Ich gehe mal davon aus, dass Du nicht die Möglichkeit meinst, den MySQL-Benutzer und dessen Passwort in einer php.ini bzw. .user.ini zu verewigen: ~~~INI mysqli.default_user = ; Default password for mysqli_connect() (doesn't apply in safe mode). ; *Any* user with PHP access can run 'echo get_cfg_var("mysqli.default_pw") ; https://php.net/mysqli.default-pw mysqli.default_pw = ~~~ Das ist aber sicherer als in Skripten unterhalb von Document-Root. --- Das kann (eigentlich, jenseits von Skript-Konstruktionen, bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird, siehe oben) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. --- Ich gehe mal davon aus, dass Du nicht die Möglichkeit meinst, den MySQL-Benutzer und dessen Passwort in einer php.ini bzw. .user.ini zu verewigen: ~~~INI mysqli.default_user = ; Default password for mysqli_connect() (doesn't apply in safe mode). ; *Any* user with PHP access can run 'echo get_cfg_var("mysqli.default_pw") ; https://php.net/mysqli.default-pw mysqli.default_pw = ~~~ Das ist aber sicherer als in Skripten unterhalb von Document-Root. --- Das kann (eigentlich, jenseits von Skript-Konstruktionen, bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird, siehe oben) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“. Ich gehe mal davon aus, dass Du nicht die Möglichkeit meinst, den MySQL-Benutzer und dessen Passwort in einer php.ini bzw. .user.ini zu verewigen: ~~~INI mysqli.default_user = ; Default password for mysqli_connect() (doesn't apply in safe mode). ; *Any* user with PHP access can run 'echo get_cfg_var("mysqli.default_pw") ; https://php.net/mysqli.default-pw mysqli.default_pw = ~~~ Das ist aber sicherer als in Skripten unterhalb von Document-Root.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“. Ich gehe mal davon aus, dass Du nicht die Möglichkeit meinst, den MySQL-Benutzer und dessen Passwort in einer php.ini bzw. .user.ini zu verewigen: ~~~ mysqli.default_user = ; Default password for mysqli_connect() (doesn't apply in safe mode). ; *Any* user with PHP access can run 'echo get_cfg_var("mysqli.default_pw") ; https://php.net/mysqli.default-pw mysqli.default_pw = ~~~ Das ist aber sicherer als in Skripten unterhalb von Document-Root.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die „versauen“ weniger oft IP-Adressen und brauchen auch deutlich seltener Support – sparen also „Manpower“.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Das der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die versauen weniger oft IP-Adressen und brauchen ja auch deutlich seltener Support.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes oder einer passenden Zeile in der Konfiguration) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Dass der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die versauen weniger oft IP-Adressen und brauchen ja auch deutlich seltener Support.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich, jenseits von Skript-Konstruktionen bei denen dem MySQL-Client ein Passwort anhand des Unix-Benutzerkennzeichens automatisch „untergejubelt“ wird) nur bei einem eigenem (virtuellem) Server der Fall sein (nicht beim „shared hosting“) und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Dass der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die versauen weniger oft IP-Adressen und brauchen ja auch deutlich seltener Support.

> ich habe auch schon Hoster gesehen, die für den Datenbankzugriff gar kein Passwort verlangen, weil aufgrund der geltenden Routing- und Firewall-Regeln der Zugriff sowieso nur von localhost kommen kann, und der darf ja immer. Das kann (eigentlich) nur bei einem eigenem Server der Fall sein und entspricht dann wohl dem, was Debian-artige beim Setup machen: Wer mittels `sudo` oder `su` Root werden kann, ist das dann (bei einer Verbindung via Socket, die der Client nutzt wenn localhost oder nichts als Server angegeben wird) auch - via MySQL/MariaDB-Client - auch ohne Passwort. Auf einem eigenem Server (ganz gleich ob Hardware oder virtuell) ist man also selbst in der Verantwortung. **Zur Frage der Sicherheit:** Wenn ein Angreifer root-Rechte auf einem Server hat, dann „war es das auch“ für die Datenbanken, denn der System-Root hat „viele schöne Möglichkeiten“ (beginnen wir bei der Option `--skip-grant-tables` beim Start des Dienstes) - dagegen hilft allenfalls das Betreiben der Datenbank in durch einen Benutzer separat verschlüsselten Containern (etwa via virtuelle Maschine oder Docker). Allerdings nur bis sich dann eine berechtigte Person dort anmeldet oder der Wörterbuch bzw. Brut-Force-Angriff auf die Verschlüsselung erfolgreich ist und nur dann wenn bei Auftauchen ungewöhnlicher Root-Prozesse die VM oder der Container und der zur Entschlüsselung notwendige Mount gecancelt wurde… Soll heißen: Dass der System-Root sich lokal und ohne Passwort an der Datenbank anmelden kann ist **keine Sicherheitslücke - das sieht nur so aus.** **Mein Fazit:** Hoster, die Linux-Server vermieten, sollten Kunden, [die einen gültigen LPIC-2 oder dergleichen nachweisen](https://www.lpi.org/de/our-certifications/lpic-2-overview), Rabatt geben. Die versauen weniger oft IP-Adressen und brauchen ja auch deutlich seltener Support.