Imagem Docker de XWINDOW em coreano com acesso via RDP no Windows
(github.com/lancard)Estou disponibilizando uma imagem Docker de XWINDOW em coreano (Wayland) baseada no mais recente Debian 13 (Trixie).
Na prática, muita gente usa Windows e, de vez em quando, pode querer subir um Linux com X Window em coreano via Docker para trabalhar.
Por isso!
Montei um ambiente GUI em coreano baseado em Debian que pode ser acessado pelo Remote Desktop do Windows.
Essa imagem já vem com ferramentas essenciais para desenvolvimento, como Visual Studio Code, Chromium, Vim, Git e Node.js + npm, então pode ser usada imediatamente como ambiente de desenvolvimento. (Por isso ela ficou um pouco grande.)
Principais características:
- Suporte a conexão via Remote Desktop do Windows (RDP)
- Persistência de dados e volumes: ao conectar
/home/(nome do usuário)a um volume Docker, os dados podem ser mantidos
Observações:
Como é executada no Docker, o VSCode e o Chromium funcionam sem o modo sandbox. Tenha atenção à segurança. O recurso de som foi removido por causa de muitos conflitos e bugs. Na minha opinião, a maioria das pessoas provavelmente escuta música no próprio PC com Windows, então optei por não incluir isso.
É uma imagem especialmente útil para usuários de coreano que querem montar rapidamente um ambiente de desenvolvimento.
O código-fonte está em https://github.com/lancard/x11-korean, então deem uma olhada. Se precisarem de alguma funcionalidade, sintam-se à vontade para abrir uma issue ou enviar um PR!
25 comentários
Consigo criar arquivos novos no
vscodeinterno, mas não consigo modificar arquivos existentes. Mesmo alterando os arquivos existentes comchmod 777. Acho que deve ser um problema de permissões ou de propriedade do grupo, então vou tentar mais algumas coisas.Parece que conseguiram contornar isso modificando o arquivo
shno ponto de entrada e ajustando oXWINDOW_USER_IDpara o ID da pasta de trabalho.definir nome de usuário
XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "usuário '$XWINDOW_USER' gerado."
fi
a parte acima foi alterada para
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # padrão 1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "usuário '$XWINDOW_USER' gerado com UID $XWINDOW_USER_ID."
else
echo "usuário '$XWINDOW_USER' já existe."
fi
assim o
USER_IDfoi definido com o mesmo ID de conta da máquina host.Dá para usar como substituto do WSL?
Sim, dá para usar. Pessoalmente, eu não gosto de WSL / WSL2, então instalei o Docker no Hyper-V e estou usando isto.
Posso perguntar com cuidado por que você não gosta disso?
Não gosto de misturar dois sistemas operacionais. Nem sei que tipo de efeito colateral isso pode ter. Acho que cada sistema operacional deveria ficar em uma sandbox ou ocupar sozinho um servidor físico. Além disso, no passado já tive experiências em que o WSL se comportava de forma estranha.
Como isso não está muito claro dentro do conhecimento que eu tenho, será que
não é parecido com a estrutura lógica básica do WSL ou do Docker?
Será que há alguma parte que eu entendi errado?
Dá para dizer que o WSL2 é um pouco parecido, mas a estrutura do WSL é um pouco diferente. Basicamente, ele roda sobre o kernel do Windows. O WSL2 realmente roda sobre um hipervisor, mas considero que o nível de isolamento é um pouco diferente. Como há montagem automática nos dois lados, os sistemas operacionais conseguem acessar o sistema de arquivos um do outro. Isso pode acabar gerando resultados indesejados. Por exemplo, o Windows pode criar automaticamente
$RECYCLE.BINno ext4, e se um dos sistemas for comprometido por um hacker, isso pode ser fatal para ambos. O que eu criei, se você quiser, pode não montar absolutamente nada. Dá para deixar rodando sozinho, sem conexão com o Windows.E a velocidade de instalação também acaba sendo afetada... no método da minha imagem, se você não gostar, é só apagar a imagem Docker e copiar outra nova. Na hora de atualizar, também basta baixar a imagem. Se bem me lembro, também havia alguns problemas na parte de rede do WSL2. Além disso, pelo que sei, o kernel Linux dele também não é um kernel Linux puro, e sim algo customizado pela Microsoft.
Isso não combina muito comigo, que busco um Linux puro (ou seja, quero que eles fiquem isolados entre si).
Acabei listando só as desvantagens, mas na verdade também entra um pouco de preferência pessoal, então você pode escolher o que preferir.
Demorei para verificar.
Obrigado pela resposta tão atenciosa!
E, como o próprio Docker é quase exclusivo de Linux, além de ser possível rodar Docker em um NAS e de haver vantagens como a distinção entre maiúsculas e minúsculas, dá para entender que isso foi feito porque usar Docker traz muitos benefícios.
No caso do modo privileged, foi ajustado para rodar no sandbox. No modo privileged, é possível conectar recursos locais (como a unidade C). Eles são montados em
$HOME/thinclient_drives.Se quiser conectar recursos locais (
C:,D:etc.), execute em modoprivileged. (Assim, a cópia de arquivos comCTRL + C / Vfunciona)Opa... parece que o VS Code não está funcionando :)
Estou respondendo à minha própria pergunta. Como não houve resposta, fui testando várias coisas e descobri que, ao executar
code --no-sandboxno terminal, ele abre.Hum? Será que o que está na área de trabalho não abriu para você?
Ah, é, não funcionou. Não sei o que fiz de errado..
Como continuo alterando a imagem, talvez você esteja vendo uma imagem intermediária.
Primeiro, verifique se o comando do ícone do vscode na área de trabalho é
/usr/bin/code %F. Abra o arquivo/usr/bin/codee confira se a penúltima linha está assim:ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"Sou alguém que começou a estudar Docker recentemente. Testei esta imagem com o
trivypara verificar vulnerabilidades e apareceram 1.053 vulnerabilidades. Não parece que todas sejam importantes; parece mais que ele captura de tudo um pouco. Na prática, vocês poderiam me dar alguma orientação sobre como verificar e alcançar a segurança de uma imagem?Na verdade, há tantas formas de eliminar vulnerabilidades que não existe uma resposta certa.
No meu caso, procuro usar a versão mais recente que esteja o mais estável possível e, ao usar GitHub Actions, deixo os security bots ativados ao máximo. Na prática, como dá para ver nesta imagem do XWINDOW, não há nenhuma parte programada por mim, então provavelmente só existirão as vulnerabilidades básicas padrão dos próprios programas instalados.
Eu fiquei curioso por que o fato de o modo sandbox não estar aplicado é uma observação de segurança importante.
O Docker não fornece recursos de sandbox para os processos internos? Então, por causa disso, não tem jeito e ele acaba tendo que ser executado como root e, mesmo sendo um ambiente isolado por Docker, isso significa que ainda existe o risco de malware invadir volumes mapeados com o host? Ou isso quer dizer que os arquivos criados pelo usuário dentro do sistema de arquivos interno do Docker podem não ser seguros?
Até onde eu sei, tanto no Windows quanto no Linux, o Chrome roda em modo sandbox. Ou seja... mesmo que alguém crie um exploit com JavaScript ou algo assim para atacar uma vulnerabilidade, isso não afeta o sistema operacional de fato.
Mas, no modo de contêiner, provavelmente é preciso ativar o modo
privilegedpara habilitar essa função.Claro, daria para orientar a ativarem esse modo, mas eu achava que o próprio contêiner já era o sandbox. Algo como um Windows que você liga e desliga facilmente, por assim dizer...
Por isso, o VS Code baseado em Chromium e Electron foi configurado para rodar em um modo sem sandbox.
Isso quer dizer apenas que, assumindo que existam vulnerabilidades no Chromium e no VS Code, e que um invasor consiga criar um exploit para explorá-las, pode haver risco.
O nome do Docker é
lancard/xwindow-korean.Como é Wayland, alterei o nome do repositório para https://github.com/lancard/xwindow-korean ~
Como o Ubuntu é da família Debian, também dá para usar
apte afins com facilidade. Achei o Debian melhor do que a imagem base do Ubuntu.