Toolbox: Ajustar caminho inicial

Eu costumo fazer HOME=/home/user1/container1 antes de criar os containers e usar um alias para abri-los. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Sim, substituir $HOME é uma maneira de fazer isso.

Também gostaria de ver algo assim. Meu principal caso de uso para o Toolbox é configurar ambientes de desenvolvimento descartáveis, para trabalhar em projetos ou apenas compilar rapidamente algum software a partir do código-fonte. Eu não quero poluir meu sistema com arquivos aleatórios de dependências, etc. apenas para compilar algo uma vez. A caixa de ferramentas parecia perfeita para isso, pois afirma fornecer um contêiner isolado para manter o host limpo.

Isso não acabou por funcionar bem como eu esperava embora. Embora o Toolbox mantenha o sistema operacional do host limpo, ele não mantém o diretório inicial limpo. Isso ainda fica totalmente poluído. Por exemplo, usando um contêiner descartável para construir algo que usa rust , meu diretório inicial acabou sendo alterado de várias maneiras:

• Um diretório ~/.cargo foi criado silenciosamente, contendo muitos binários relacionados ao Rust, pacotes fonte, etc. para um total de 123 MB.
• Um diretório ~/.rustup foi criado silenciosamente, contendo muitos outros binários relacionados ao Rust, para um total de 683 MB.
• Meu arquivo ~/.bash_profile foi alterado silenciosamente para adicionar o diretório ~/.cargo/bin ao meu $PATH antes de todo o resto.
• Meu arquivo ~/.profile foi alterado silenciosamente para adicionar o diretório ~/.cargo/bin ao meu $PATH antes de todo o resto.
• Quem sabe o que mais.

Caramba. O que deveria ser um sistema temporário, descartável e fácil de descartar resultou em muitas mudanças permanentes sendo feitas silenciosamente no meu diretório pessoal. Percebo agora pelos comentários acima que posso substituir a variável de ambiente $HOME manualmente para tentar contornar isso, mas isso não era intuitivo ou esperado para mim. Como o Toolbox deve ser (ou pelo menos como eu o entendo) uma maneira simplificada e amigável de entrar em contêineres, eu apreciaria se isso pudesse ser tratado de uma maneira melhor.

Minha opinião é que uma caixa de ferramentas provavelmente deve ter seu próprio usuário exclusivo e diretório inicial por padrão. Mas se isso for muito complicado de implementar, talvez possa haver pelo menos um argumento -h ou --home ao criar uma nova caixa de ferramentas, para definir seu $HOME padrão? Para que, quando você entrar na caixa de ferramentas no futuro, esse valor $HOME seja definido automaticamente. Por exemplo, algo toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

Basicamente, acho que seria ótimo se o Toolbox tivesse uma maneira fácil de configurar um contêiner em um dos três modos:

1. Modo contínuo: como funciona agora. O usuário do contêiner age como se fosse seu usuário host real, compartilhando seu diretório inicial.
2. Modo semi-isolado: o contêiner tem acesso aos arquivos do usuário do host, mas possui seu próprio diretório inicial para o software usar por padrão. Você precisaria acessar manualmente o diretório inicial do usuário do host se quiser ler/gravar nele. Seria basicamente como o modo Seamless acima, mas com seu próprio diretório de trabalho separado.
3. Modo totalmente isolado (não confiável): o contêiner teria seu próprio usuário e diretório inicial separados, sem absolutamente nenhum acesso ao diretório inicial do usuário do host. Isso seria útil para executar software não confiável, que você não deseja permitir que leia tudo em seu diretório pessoal.

Isso soa muito razoável para mim. O que você acha @debarshiray??

Eu apoio esta @JaneSmith , tudo que eu preciso - muito bem colocado!

Também apoio a ideia. Mas até que seja implementado, você pode usar direnv . É uma ferramenta útil que permite especificar variáveis ​​de ambiente por diretório. Você pode usar o seguinte fluxo de trabalho

- install direnv and hook it to your shell
- create a temporary directory eg. ~/somedev
- add a .envrc file with the environment variables you want (in this case HOME=/home/user/somedev

agora, toda vez que você entrar no diretório somedev , ele assumirá que é o diretório inicial e será redefinido quando você sair dele. Você pode fazer todas as etapas depois de instalar o direnv em um comando como:

``` bash
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
Atualmente, uso um fluxo de trabalho semelhante.

Concordo que deve haver pelo menos uma opção para não montar o diretório inicial (ref https://github.com/containers/toolbox/issues/183#issuecomment-623103780). Na verdade, eu ficaria bem se ele usasse - semelhante ao flatpak - algum diretório em ~/.var/app , talvez melhor ~/.var/toolbox ou algo assim, onde todos os arquivos no diretório inicial são salvos por padrão.
Eu gosto bastante desse modelo flatpak, porque você tem todos os dados de um contêiner em um só lugar e, se você excluir o contêiner, também poderá excluir todos os dados do aplicativo. (ou apenas meça o espaço que seu novo projeto "Eu experimentei a ferrugem"), por exemplo (como é feito no gnome-control-center)

Então, por conveniência, ele deve sempre ser montado no $PWD atual, se você iniciá-lo a partir de uma pasta de projeto, provavelmente espera ter os arquivos lá. Apenas, sua pasta ~/rust-project , não precisa de nenhum acesso a ~/Pictures/private/… etc.

De qualquer forma, é claro que se deve poder opcionalmente montar home como somente leitura ou até mesmo gravável, mas não acho que isso seja realmente necessário para a maioria dos aplicativos.
E deve-se ser capaz de não montar o atual $PWD .

Então você teria um "meio-termo" aqui como um novo padrão.

tlbx fork tem uma opção -n para não ligar o diretório inicial.

Duplicado de https://github.com/containers/toolbox/issues/183

Nãooooo… você ainda pode ter outros casos de uso/razões para ter um $HOME diferente do que um "Ambientes de desenvolvimento isolados para se defender de bugs e malware no código em desenvolvimento"…

IMHO, esse ainda é um recurso que a caixa de ferramentas deve ter.

Não entendo porque esse problema foi encerrado. Não é uma duplicata disso. Não se trata apenas de segurança. Eu realmente espero que isso seja reconsiderado, pois eu amo o Fedora Silverblue e adoro que ele tenha uma ferramenta embutida para configurar contêineres para animais de estimação, mas ele realmente não faz o trabalho atualmente. Eu não quero ter que usar um fork só para isso... Eu uso toolbox para pet containers para lidar com vários projetos de programação, e eu não quero que meu diretório home fique cheio de containers. Não tem nada a ver com segurança.

@JaneSmith, por que não usar um garfo se ele tiver os recursos que você precisa?

Prefiro usar o Toolbox em vez de um fork, porque o Toolbox é mais bem suportado com mais desenvolvedores e está incluído no Fedora pronto para uso. Quando estou mudando de máquina para máquina, o Toolbox já está lá, sem que eu precise instalar garfos. Parte do motivo para usar o Toolbox em primeiro lugar é evitar sobrecarregar meu sistema com instalações aleatórias de software!

Na minha humilde opinião, esta solicitação de recurso é para algo que deveria ser uma funcionalidade básica, básica, já que não tê-lo meio que anula o propósito do Toolbox. Eu não vejo isso como um recurso especial incomum realmente "lá fora". Estou, portanto, expressando meu apoio e esperando que seja implementado para este projeto.

@JaneSmith Concordo em todos os pontos. Espero que o recurso seja implementado na primeira vez que o design inseguro atual for divulgado para desempenhar um papel em uma violação de segurança, se não antes.

A primeira frase na documentação diz que roda _totalmente sem privilégios _. Parece seguro, hein?

Também na descrição principal: _A intenção desses sistemas é desencorajar a instalação de software no host e, em vez disso, instalar software como (ou em) contêineres._ Também parece que esse projeto deve adicionar segurança significativa.

Em nenhum lugar os documentos destacam que está compartilhando todos os documentos com os quais seu usuário possui com todos os contêineres, incluindo chaves SSH e arquivos não relacionados ao que está acontecendo no contêiner.

A situação atual não é apenas insegura, mas induz ao erro de transmitir que o uso de contêineres como esse fornece segurança significativa, quando dificilmente os contêineres podem acessar todos os seus arquivos!

Se você procurar por "home" no README, não há documentação de que seu diretório pessoal seja compartilhado dessa maneira.

Eu quero isso também. Um meio termo (casa acessível, mas não definido como HOME) e um modo mais não confiável (casa não acessível).

Eu costumo fazer HOME=/home/user1/container1 antes de criar os containers e usar um alias para abri-los. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Se uma solução intermediária é tão simples... então por que não pode ser implementada no Toolbox como uma opção? Basta usar o caminho inicial como um argumento ao criar a caixa de ferramentas e salvá-lo em algum lugar, provavelmente da mesma maneira que o nome do contêiner é salvo. Em seguida, leia esse caminho e defina-o ao entrar no contêiner ...

Para tornar as coisas um pouco mais concretas:

• --new-home que diria ao toolbox enter para não montar o host $HOME (ou montá-lo em outro lugar no contêiner que não seja $HOME)
• --from-home path1:path2:pathN que diria ao toolbox enter para montar caminhos específicos do host $HOME para o container home

Então, por exemplo, se eu tiver diretórios de origem em ~/Projects, precisar assinar coisas com gpg e precisar de ssh para conectar a um servidor e minha configuração do git, eu poderia criar uma caixa de ferramentas assim:

toolbox create --new-home --from-home Projects:.ssh:.gnupg:.gitconfig

Então, isso é algo que seria aceito a montante? Eu até trabalharia nisso se o plano fizesse sentido.