Koreanisches XWINDOW-Docker-Image mit Zugriff per Windows-RDP
(github.com/lancard)Ich habe ein koreanisches XWINDOW-(Wayland)-Docker-Image auf Basis des neuesten Debian 13 (Trixie) erstellt und veröffentlicht.
Viele von euch nutzen tatsächlich Windows, und manchmal möchte man über Docker ein Linux-XWindow mit Koreanisch-Unterstützung starten und darin arbeiten.
Deshalb!
Ich habe eine Debian-basierte koreanische GUI-Umgebung erstellt, auf die per Windows-Remotedesktop zugegriffen werden kann.
In diesem Image sind wichtige Tools für die Entwicklungsumgebung wie Visual Studio Code, Chromium, Vim, Git, Node.js + npm bereits vorinstalliert, sodass es sofort als Entwicklungsumgebung genutzt werden kann. (Dadurch ist es allerdings etwas groß.)
Zu den wichtigsten Merkmalen gehören:
- Verbindung per Windows-Remotedesktop (RDP) möglich
- Daten- und Volume-Erhalt: Wenn
/home/(Benutzername)mit einem Docker-Volume verbunden wird, bleiben die Daten dauerhaft erhalten
Zu beachten ist:
Da es in Docker ausgeführt wird, werden VSCode und Chromium nicht im Sandbox-Modus betrieben. Bitte achtet daher auf die Sicherheit. Die Audiofunktion wurde wegen häufiger Konflikte und Bugs entfernt. Meiner Einschätzung nach hören die meisten ohnehin Musik auf ihrem Windows-PC, daher habe ich sie weggelassen.
Das ist ein besonders nützliches Image für koreanischsprachige Nutzer, die schnell eine Entwicklungsumgebung aufbauen möchten.
Den Quellcode findet ihr unter https://github.com/lancard/x11-korean. Wenn ihr Funktionen braucht, erstellt jederzeit gerne ein Issue oder PR!
25 Kommentare
In dem internen VS Code kann ich zwar neue Dateien erstellen, vorhandene Dateien aber nicht bearbeiten. Auch wenn ich bestehende Dateien mit
chmod 777ändere. Es scheint ein Problem mit Berechtigungen oder Gruppenbesitz zu sein, ich werde noch ein paar weitere Dinge ausprobieren.Es scheint, als hätte man das Problem gelöst, indem man die
sh-Datei im Entry Point angepasst undXWINDOW_USER_IDauf die ID des Arbeitsordners abgestimmt hat.set username
XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi
den Teil
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # Standardwert 1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi
geändert und
USER_IDauf dieselbe Konto-ID wie auf dem Host-System gesetzt.Kann man das als Ersatz für WSL verwenden?
Ja, das geht. Ich persönlich mag WSL / WSL2 nicht, deshalb habe ich Docker auf Hyper-V installiert und nutze das hier.
Darf ich vorsichtig fragen, warum Sie es nicht mögen?
Ich mag es nicht, wenn zwei Betriebssysteme miteinander vermischt werden. Man weiß nie, welche Side Effects auftreten könnten. Meiner Meinung nach sollte jedes Betriebssystem in einer Sandbox laufen oder einen physischen Server exklusiv belegen. Außerdem habe ich in der Vergangenheit schon erlebt, dass WSL merkwürdig funktioniert hat.
Soweit ich es aus meinem Wissensstand heraus beurteilen kann, verstehe ich die von Ihnen angesprochenen Inhalte nicht ganz.
Ist das möglicherweise nicht ähnlich zur grundlegenden logischen Struktur von WSL oder Docker?
Gibt es einen Punkt, den ich falsch verstanden habe?
Man könnte sagen, dass WSL2 ein wenig ähnlich ist, aber die Struktur von WSL ist etwas anders. Grundsätzlich läuft es auf dem Windows-Kernel. Bei WSL2 stimmt es zwar, dass es auf einem Hypervisor läuft, aber ich denke, das Isolationsniveau ist etwas anders. Da automatische Mounts in beide Richtungen erfolgen, können die Betriebssysteme auf die Dateisysteme des jeweils anderen zugreifen. Dadurch können unerwünschte Ergebnisse entstehen. Zum Beispiel kann Windows automatisch
$RECYCLE.BINauf ext4 anlegen, und wenn eines der beiden Betriebssysteme von einem Hacker übernommen wird, ist das für beide Seiten kritisch. Bei meiner Lösung muss auf Wunsch gar nichts gemountet werden. Man kann sie ohne Verbindung zu Windows komplett eigenständig laufen lassen.Außerdem hat das wohl auch Auswirkungen auf die Installationsgeschwindigkeit ... Wenn einem mein Image-Ansatz nicht gefällt, löscht man einfach das Docker-Image und kopiert ein neues. Auch bei Updates muss man nur das Image herunterladen. Ich meine mich außerdem zu erinnern, dass es bei WSL2 auch einige Probleme auf der Netzwerkseite gab. Soweit ich weiß, ist auch der Linux-Kernel dort kein reiner Linux-Kernel, sondern von Microsoft angepasst.
Für mich, der auf ein pures Linux abzielt (also auf eine gegenseitige Isolierung Wert legt), passt das nicht so gut.
Ich habe jetzt zwar nur die Nachteile aufgezählt, aber letztlich ist das auch ein Stück weit Geschmackssache, daher können Sie einfach das wählen, was Sie bevorzugen.
Ich habe es erst spät gesehen.
Vielen Dank für die ausführliche Antwort!
Und Docker selbst ist zudem fast nur für Linux gedacht, und man kann Docker auf einem NAS ausführen; auch die Unterscheidung zwischen Groß- und Kleinschreibung sowie viele weitere Vorteile sprechen für Docker, weshalb ich das so erstellt habe.
Im Fall des
privileged modewurde es so angepasst, dass es in der Sandbox läuft. Im Fall desprivileged modekönnen lokale Ressourcen (C-Laufwerk usw.) verbunden werden. Die Verbindung wird unter$HOME/thinclient_driveseingehängt.Wenn Sie lokale Ressourcen (
C:,D:usw.) verbinden möchten, führen Sie es imprivileged-Modus aus. (Dann funktioniert auch das Kopieren von Dateien mitCTRL + C/V.)Hooook … VS Code lässt sich wohl nicht ausführen :)
Ich antworte mir selbst: Da keine Reaktion kam, habe ich dies und das ausprobiert, und wenn ich im Terminal
code --no-sandboxausführe, öffnet es sich.Hm? Könnte es sein, dass sich das auf dem Desktop nicht geöffnet hat?
Ah, nein, es hat nicht funktioniert. Was ich falsch gemacht habe …
Da ich das Image laufend ändere, könnte es sein, dass es sich um ein Zwischen-Image handelt.
Prüfen Sie zunächst, ob beim
vscode-Symbol auf dem Desktop als Befehl/usr/bin/code %Feingetragen ist,und öffnen Sie dann die Datei
/usr/bin/code, um zu kontrollieren, ob die vorletzte ZeileELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"lautet.
Ich beschäftige mich in letzter Zeit mit Docker. Ich habe die Schwachstellen dieses Images mit
trivygeprüft und dabei 1053 Schwachstellen gefunden. Es wirkt nicht so, als wären alle davon wichtig, eher so, als würde einfach alles Mögliche erkannt werden. Könnten Sie mir vielleicht praxisnah einen Rat geben, wie man die Sicherheit eines Images überprüft und sicherstellt?Tatsächlich gibt es so viele Methoden zur Beseitigung von Schwachstellen, dass es keine eindeutig richtige Antwort gibt.
In meinem Fall nutze ich möglichst die neueste stabile Version, und wenn ich GitHub Actions verwende, aktiviere ich Security-Bots so weit wie möglich. Tatsächlich hat dieses XWINDOW-Image, wie Sie sehen können, keinen programmierten Anteil, daher wird es wahrscheinlich nur die grundlegenden, inhärenten Schwachstellen der installierten Programme selbst geben.
Ich habe mich gefragt, warum der Umstand, dass der Sandbox-Modus nicht angewendet wurde, als Sicherheitshinweis gilt.
Bedeutet das, dass Docker internen Prozessen keine Sandbox-Funktion bereitstellt? Deshalb lässt es sich zwangsläufig nur als Root ausführen, und selbst wenn es sich um eine durch Docker isolierte Umgebung handelt, besteht dann das Risiko, dass Schadsoftware in mit dem Host gemappte Volumes eindringen kann? Oder bedeutet es, dass vom Benutzer innerhalb des Docker-Containers erstellte Dateien im internen Dateisystem möglicherweise nicht sicher sind?
Soweit ich weiß, läuft Chrome sowohl unter Windows als auch unter Linux im Sandbox-Modus. Das heißt ... selbst wenn jemand etwa über JavaScript einen Exploit baut und eine Schwachstelle angreift, hat das keine Auswirkungen auf das eigentliche OS.
Im Container-Modus muss man dafür aber wahrscheinlich den
privileged-Modus aktivieren.Natürlich könnte man auch anweisen, diesen Modus einzuschalten, aber ich habe den Container selbst als eine Art Sandbox betrachtet. So ein bisschen wie ein Fenster, das man einfach ein- und ausschalten kann ...
Deshalb habe ich Chromium und das auf Electron basierende VS Code so konfiguriert, dass sie nicht im Sandbox-Modus laufen.
Das heißt nur: Wenn es in Chromium und VS Code Schwachstellen gibt und ein Angreifer diese ausnutzen kann, um einen Exploit zu bauen, dann könnte das gefährlich sein.
Der Docker-Name ist
lancard/xwindow-korean.Da es Wayland ist, habe ich den Repo-Namen in https://github.com/lancard/xwindow-korean geändert~
Da Ubuntu zur Debian-Familie gehört, können Sie
aptund Ähnliches bequem nutzen. Ich fand Debian besser als das Standard-Ubuntu-Image.