Toolbox: Ajustar la ruta de inicio

Por lo general, solo hago HOME=/home/user1/container1 antes de crear los contenedores y solo uso un alias para abrirlos. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Sí, anular $HOME es una forma de hacerlo.

También me gustaría ver algo como esto. Mi caso de uso principal para Toolbox es configurar entornos de desarrollo desechables, ya sea para trabajar en proyectos o simplemente para compilar rápidamente algún software desde la fuente. No quiero contaminar mi sistema con archivos aleatorios de dependencias, etc. solo para compilar algo una vez. Toolbox parecía perfecto para esto, ya que afirma proporcionar un contenedor aislado para mantener limpio el host.

Sin embargo, esto no resultó funcionar como esperaba. Si bien Toolbox mantiene limpio el sistema operativo host, no mantiene limpio el directorio de inicio en absoluto. Eso todavía se contamina totalmente. Por ejemplo, al usar un contenedor desechable para construir algo que usa rust , mi directorio de inicio terminó siendo alterado de varias maneras:

• Se creó silenciosamente un directorio ~/.cargo , que contiene muchos archivos binarios, paquetes fuente, etc. relacionados con Rust para un total de 123 MB.
• Se creó silenciosamente un directorio ~/.rustup , que contiene muchos más archivos binarios relacionados con Rust, para un total de 683 MB.
• Mi archivo ~/.bash_profile se modificó silenciosamente para agregar el directorio ~/.cargo/bin a mi $PATH antes que todo lo demás.
• Mi archivo ~/.profile se modificó silenciosamente para agregar el directorio ~/.cargo/bin a mi $PATH antes que todo lo demás.
• Quién sabe qué más.

¡Ay! Lo que se suponía que era un sistema temporal, descartable y fácil de descartar resultó en muchos cambios permanentes que se realizaron silenciosamente en mi directorio de inicio. Ahora me doy cuenta de los comentarios anteriores que puedo anular la variable de entorno $HOME manualmente para intentar solucionar esto, pero esto no fue intuitivo ni esperado para mí. Dado que se supone que Toolbox es (o al menos como yo lo entiendo) una forma simplificada y fácil de usar para ingresar a los contenedores, agradecería que esto se pueda manejar de una mejor manera.

Mi opinión es que una caja de herramientas probablemente debería tener su propio usuario único y directorio de inicio por defecto. Pero si esto es demasiado complicado de implementar, entonces tal vez podría haber al menos un argumento -h o --home al crear una nueva caja de herramientas, para establecer su $HOME predeterminado. De modo que cuando ingrese a la caja de herramientas en el futuro, obtendrá ese valor de $HOME establecido automáticamente. Por ejemplo, algo toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

Básicamente, creo que sería genial si Toolbox tuviera una forma fácil de configurar un contenedor en uno de estos tres modos:

1. Modo continuo: cómo funciona ahora. El usuario del contenedor actúa como si fuera su usuario host real y comparte su directorio de inicio.
2. Modo semiaislado: el contenedor tiene acceso a los archivos de su usuario host, pero tiene su propio directorio de inicio para que el software lo use de forma predeterminada. Deberá acceder manualmente al directorio de inicio de su usuario host si desea leer/escribir allí. Básicamente sería como el modo Seamless anterior, pero con su propio directorio de trabajo separado.
3. Modo completamente aislado (no confiable): el contenedor tendría su propio usuario y directorio de inicio separados, sin ningún acceso al directorio de inicio del usuario del host. Esto sería útil para ejecutar software no confiable, que no desea permitir que lea todo en su directorio de inicio.

Esto suena muy razonable para mí. Que opinas @debarshiray??

Apoyo a @JaneSmith , todo lo que necesito, ¡bien dicho!

Yo también secundo la idea. Pero hasta que se implemente, podría usar direnv . Es una herramienta útil que permite especificar variables de entorno por directorio. Puede utilizar el siguiente flujo de trabajo

- 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

ahora, cada vez que ingrese al directorio somedev , asumirá que es el directorio de inicio y se reiniciará cuando salga de él. Podría hacer todos los pasos después de instalar direnv en un comando como:

golpe ```
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
Actualmente uso un flujo de trabajo similar.

Acepto que al menos debería haber una opción para no montar el directorio de inicio (ref https://github.com/containers/toolbox/issues/183#issuecomment-623103780). En realidad, incluso estaría bien si usa, similar a flatpak, algún directorio en ~/.var/app , tal vez mejor ~/.var/toolbox más o menos, donde todos los archivos en el directorio de inicio se guardan de manera predeterminada.
Me gusta bastante ese modelo flatpak, porque tiene todos los datos de un contenedor en un solo lugar, y si elimina el contenedor, también puede eliminar todos los datos de la aplicación. (o simplemente mida el espacio que tomó su nuevo proyecto "He probado el óxido"), por ejemplo (como se hace en gnome-control-center)

Luego, por conveniencia, posiblemente siempre debería montarse en el $PWD actual, si lo inicia desde una carpeta de proyecto, es probable que espere tener los archivos allí. Simplemente, su carpeta ~/rust-project , no necesita ningún acceso a ~/Pictures/private/… etc.

De todos modos, por supuesto, uno debería poder montar opcionalmente home como de solo lectura o incluso de escritura, pero no creo que sea realmente necesario para la mayoría de las aplicaciones.
Y uno debería poder no montar el $PWD actual.

Así que tendrías un "término medio" aquí como un nuevo valor predeterminado.

La bifurcación tlbx tiene una opción -n para no montar el directorio de inicio.

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

Noooo... todavía puede tener otros casos de uso/razones para tener un $HOME diferente y luego un "Entorno de desarrollo aislado para defenderse de errores y malware en el código en desarrollo"...

En mi humilde opinión, esta sigue siendo una característica que la caja de herramientas debería tener.

No entiendo por qué se cerró este tema. No es un duplicado de eso. No se trata solo de seguridad. Realmente espero que esto se reconsidere, ya que me encanta Fedora Silverblue y me encanta que tenga una herramienta integrada para configurar contenedores para mascotas, pero en realidad no hace el trabajo actualmente. No quiero tener que usar una bifurcación solo para eso... Uso la caja de herramientas para contenedores de mascotas para lidiar con varios proyectos de programación, y no quiero que mi directorio de inicio esté lleno de contenedores. No tiene nada que ver con la seguridad.

@JaneSmith, ¿por qué no usar una bifurcación si tiene las funciones que necesita?

Preferiría usar Toolbox en lugar de una bifurcación, porque Toolbox es mejor compatible con más desarrolladores y se incluye con Fedora de fábrica. Cuando me muevo de una máquina a otra, Toolbox ya está allí, sin tener que instalar horquillas. ¡Parte de la razón para usar Toolbox en primer lugar es evitar saturar mi sistema con instalaciones de software aleatorias!

En mi humilde opinión, esta solicitud de función es para algo que debería ser una funcionalidad básica básica, ya que no tenerla anula el propósito de Toolbox. No lo veo como una característica especial inusual realmente "allá afuera". Por lo tanto, expreso mi apoyo y espero que se implemente para este proyecto.

@JaneSmith Estoy de acuerdo en todos los puntos. Espero que la función se implemente la primera vez que se publique el diseño inseguro actual para jugar un papel en una brecha de seguridad, si no antes.

La primera oración en los documentos dice que se ejecuta _totalmente sin privilegios_. Suena seguro, ¿eh?

También en la descripción principal: _La intención de estos sistemas es desalentar la instalación de software en el host y, en su lugar, instalar software como (o en) contenedores._ También parece que este proyecto debe agregar seguridad significativa.

En ninguna parte los documentos resaltan que está compartiendo cada documento que posee su usuario con cada contenedor, incluidas las claves SSH y los archivos no relacionados con lo que sucede en el contenedor.

La situación actual no solo es insegura, sino que induce a error al transmitir que el uso de contenedores como este brinda una seguridad significativa, ¡cuando es casi imposible que los contenedores puedan acceder a todos sus archivos!

Si busca "inicio" en el LÉAME, no hay documentación que indique que su directorio de inicio se comparte de esta manera.

Yo también quiero esto. Un término medio (hogar accesible, pero no definido como HOGAR) y un modo menos confiable (hogar no accesible en absoluto).

Por lo general, solo hago HOME=/home/user1/container1 antes de crear los contenedores y solo uso un alias para abrirlos. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Si una solución intermedia es así de simple... entonces, ¿por qué no se puede implementar en Toolbox como una opción? Simplemente tome la ruta de inicio como argumento al crear la caja de herramientas y guárdela en algún lugar, probablemente de la misma manera que se guarda el nombre del contenedor. Luego lea esa ruta y configúrela al ingresar al contenedor ...

Para hacer las cosas un poco más concretas:

• --new-home que le indicaría a la caja de herramientas que ingrese para no montar el host $HOME (o montarlo en otro lugar del contenedor que no sea $HOME)
• --from-home path1:path2:pathN que le indicaría a la caja de herramientas que ingrese para montar rutas específicas desde el host $HOME hasta el hogar del contenedor

Entonces, por ejemplo, si tengo directorios de origen en ~/Proyectos, necesito firmar cosas con gpg y necesito ssh para conectarme a un servidor y mi configuración de git, podría crear una caja de herramientas como esta:

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

Entonces, ¿es esto algo que se aceptaría aguas arriba? Incluso trabajaría en esto si el plan tiene sentido.