Imagen Docker de XWINDOW en coreano accesible por RDP desde Windows
(github.com/lancard)Comparto una imagen Docker de XWINDOW en coreano (wayland) basada en la más reciente Debian 13 (Trixie).
En la práctica, mucha gente usa Windows, y a veces quieren levantar un Linux X Window con soporte para coreano en Docker para trabajar.
Así que
preparé un entorno GUI en coreano basado en Debian al que se puede acceder mediante Escritorio remoto de Windows.
Esta imagen incluye por defecto herramientas clave necesarias para un entorno de desarrollo, como Visual Studio Code, Chromium, Vim, Git y Node.js + npm, por lo que puede usarse de inmediato como entorno de desarrollo. (Por eso también es algo pesada)
Sus características principales son:
- Permite conexión por Escritorio remoto de Windows (RDP)
- Conservación de datos y volúmenes: si conectas
/home/(nombre_de_usuario)a un volumen de Docker, los datos pueden persistir
Como puntos a tener en cuenta,
al ejecutarse en Docker, VSCode y Chromium no usan el modo sandbox. Por favor, tomen precauciones de seguridad. Además, la función de sonido fue excluida porque tenía muchos conflictos y errores. En mi opinión, la mayoría probablemente escucha música desde su PC con Windows, así que la dejé fuera.
Es una imagen especialmente útil para usuarios coreanohablantes que quieren montar rápido un entorno de desarrollo.
El código fuente está en https://github.com/lancard/x11-korean, así que échenle un vistazo, y si necesitan alguna función, no duden en enviar un issue o un PR.
25 comentarios
Dentro de
vscodesí se pueden crear archivos nuevos, pero no se pueden modificar los archivos existentes. Incluso cambiando los archivos existentes conchmod 777. Parece que podría ser un problema de permisos o de propiedad del grupo, así que voy a seguir probando varias cosas.Parece que lo resolvieron modificando el archivo
shen el punto de entrada y ajustandoXWINDOW_USER_IDal ID de la carpeta de trabajo.La parte
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
la cambié por
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # predeterminado 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
para que
USER_IDquedara igual que el ID de cuenta de la máquina host.¿Podría usarse como sustituto de WSL?
Sí, se puede usar. Personalmente no me gusta WSL / WSL2, así que tengo Docker instalado en Hyper-V y estoy usando esto.
¿Podría preguntar con cuidado por qué no le gusta?
No me gusta mezclar dos sistemas operativos. No sé qué tipo de efectos secundarios podría haber. Creo que cada sistema operativo debería estar aislado en un sandbox o ocupar por sí solo un servidor físico. Además, en el pasado tuve una experiencia en la que WSL funcionaba de forma extraña.
Como no termino de entender bien lo que comenta desde lo que yo sé, ¿podría ser que no sea parecido a la estructura lógica básica de WSL o Docker?
¿Hay alguna parte que yo haya entendido mal?
Se podría decir que WSL2 es algo parecido, pero WSL tiene una estructura un poco distinta. Básicamente funciona sobre el kernel de Windows. Es cierto que WSL2 corre sobre un hipervisor, pero creo que el nivel de aislamiento es un poco diferente. Como hace montaje automático en ambos lados, cada SO puede acceder al sistema de archivos del otro. Y eso puede generar resultados no deseados. Por ejemplo, que Windows cree automáticamente
$RECYCLE.BINen ext4, o si uno de los dos SO cae bajo control de un hacker, sería crítico para ambos. Lo que hice yo, si se quiere, puede no montar absolutamente nada. Puede correr por su cuenta sin conectarse con Windows.Y también influye en la velocidad de instalación... con el método de mi imagen, si no te gusta, simplemente borras la imagen de Docker y copias otra nueva. Incluso al actualizar, solo necesitas descargar la imagen. También recuerdo que hubo algunos problemas del lado de la red en WSL2. Además, según entiendo, el kernel de Linux tampoco es un kernel Linux puro, sino uno personalizado por Microsoft.
No va mucho conmigo, porque yo apunto a Linux puro (o sea, a querer que estén aislados entre sí).
Aunque enumeré solo desventajas, la verdad es que también depende un poco de las preferencias personales, así que puedes elegir lo que quieras.
Lo confirmé tarde.
¡Muchas gracias por tu respuesta tan detallada!
Y además, Docker en sí es prácticamente solo para Linux, y también hay muchas ventajas en usar Docker, como ejecutarlo sobre un NAS o la distinción entre mayúsculas y minúsculas, así que pueden verlo como algo hecho por esos beneficios.
En el caso de
privileged mode, lo modifiqué para que se ejecute dentro del sandbox. Enprivileged mode, se pueden conectar recursos locales (como la unidad C). La conexión se monta en$HOME/thinclient_drives.Si quieres conectar recursos locales (como
C:oD:), ejecútalo en modoprivileged. (Entonces funciona la copia de archivos conCTRL + C / V)Uuuy... parece que VS Code no se ejecuta :)
Me respondo a mí mismo: como no hubo respuesta, estuve probando varias cosas y resulta que se abre si lo ejecuto en la terminal con
code --no-sandbox.¿Eh? ¿Quizás no se le abrió lo que estaba en el escritorio?
Ah, sí, no funcionó. Qué habré hecho mal...
Como sigo modificando la imagen, puede que la vean como una imagen intermedia.
Primero, revisen si el ícono de vscode en el escritorio tiene como comando
/usr/bin/code %F,y abran el archivo
/usr/bin/codepara verificar si la penúltima línea está así:ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@".
Últimamente he estado estudiando Docker. Probé escanear las vulnerabilidades de esta imagen con trivy y salieron 1053 vulnerabilidades. No parece que todas sean importantes, más bien da la impresión de que detecta de todo un poco, pero ¿podrían darme algún consejo sobre cómo se verifica y se logra en la práctica la seguridad de una imagen?
La verdad es que hay tantas formas de eliminar vulnerabilidades que no existe una respuesta correcta.
En mi caso, uso la versión más reciente que sea lo más estable posible y, cuando uso GitHub Actions, activo al máximo los bots de seguridad. De hecho, como podrán ver, esta imagen de XWindow no tiene ninguna parte programada, así que probablemente solo tenga las vulnerabilidades básicas propias de los programas instalados.
Me preguntaba por qué el hecho de que no se haya aplicado el modo sandbox es una consideración de seguridad.
¿Eso significa que Docker no proporciona una función de sandbox para los procesos internos? ¿Por eso inevitablemente tiene que ejecutarse como root y, aunque sea un entorno aislado con Docker, existe el riesgo de que malware comprometa los volúmenes mapeados con el host? ¿O significa que los archivos creados por el usuario dentro del sistema de archivos interno de Docker podrían no ser seguros?
Hasta donde yo sé, tanto en Windows como en Linux, Chrome funciona en modo sandbox. O sea... incluso si alguien crea un exploit con JavaScript o algo así para atacar una vulnerabilidad, no afectaría al sistema operativo real.
Pero en modo contenedor, probablemente solo se puede activar esa función si se habilita el modo
privileged.Claro, también se podría indicar que activen ese modo, pero yo pensaba que el contenedor en sí ya era un sandbox. Algo así como una ventana que puedes abrir y cerrar fácilmente, por decirlo de alguna manera...
Por eso Chromium y VS Code basado en Electron están configurados para ejecutarse en un modo sin sandbox.
Lo que quiero decir es que, asumiendo que existan vulnerabilidades en Chromium y VS Code, y que un atacante pueda aprovecharlas para crear un exploit, sí podría ser riesgoso.
El nombre de Docker es
lancard/xwindow-korean.Como es
wayland, cambié el nombre del repo a https://github.com/lancard/xwindow-korean ~Como Ubuntu pertenece a la familia Debian, también puedes usar cómodamente
apty similares. Al final, Debian me pareció mejor que la imagen base de Ubuntu.