Toolbox: Скорректировать домашний путь

Обычно я просто делаю HOME=/home/user1/container1 перед созданием контейнеров и просто использую псевдоним для их открытия. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Да, переопределение $HOME — это один из способов сделать это.

Я бы тоже хотел увидеть что-то подобное. Мой основной вариант использования Toolbox — настройка одноразовых сред разработки либо для работы над проектами, либо для быстрой компиляции некоторого программного обеспечения из исходного кода. Я не хочу загрязнять свою систему случайными файлами из зависимостей и т. д., просто чтобы скомпилировать что-то один раз. Toolbox идеально подходит для этого, так как он утверждает, что предоставляет изолированный контейнер для поддержания чистоты хоста.

Это оказалось не совсем так, как я ожидал. В то время как Toolbox поддерживает чистоту хост-ОС, он вообще не поддерживает чистоту домашнего каталога. Это все еще становится полностью загрязненным. Например, при использовании одноразового контейнера для создания чего-то, что использует rust , мой домашний каталог был изменен несколькими способами:

• Был автоматически создан каталог ~/.cargo , содержащий множество связанных с Rust двоичных файлов, пакетов с исходным кодом и т. д., всего 123 МБ.
• Был автоматически создан каталог ~/.rustup , содержащий множество других двоичных файлов, связанных с Rust, общим объемом 683 МБ.
• Мой файл ~/.bash_profile был незаметно изменен, чтобы добавить каталог ~/.cargo/bin в мой $PATH раньше всего остального.
• Мой файл ~/.profile был незаметно изменен, чтобы добавить каталог ~/.cargo/bin в мой $PATH раньше всего остального.
• Кто знает, что еще.

Угу. То, что должно было быть временной одноразовой системой, которую легко выбросить, привело к тому, что в мой домашний каталог было незаметно внесено множество постоянных изменений. Теперь из комментариев выше я понял, что я могу вручную переопределить переменную среды $HOME, чтобы попытаться обойти это, но это было не интуитивно или ожидаемо для меня. Поскольку Toolbox должен быть (или, по крайней мере, насколько я понимаю) упрощенным и удобным для пользователя способом доступа к контейнерам, я был бы признателен, если бы это можно было сделать лучше.

Я считаю, что Toolbox по умолчанию должен иметь своего уникального пользователя и домашний каталог. Но если это слишком сложно реализовать, то, возможно, при создании нового набора инструментов может быть хотя бы аргумент -h или --home , чтобы установить $HOME по умолчанию? Так что, когда вы войдете в панель инструментов в будущем, это значение $HOME будет установлено автоматически. Например, что-то вроде toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

В принципе, я думаю, было бы здорово, если бы в Toolbox был удобный способ настроить контейнер в одном из трех режимов:

1. Бесшовный режим: как это работает сейчас. Пользователь-контейнер действует так, как будто это ваш реальный пользователь хоста, который использует ваш домашний каталог.
2. Полуизолированный режим: Контейнер имеет доступ к файлам пользователя хоста, но имеет собственный домашний каталог для программного обеспечения, используемого по умолчанию. Вам нужно будет вручную получить доступ к домашнему каталогу пользователя хоста, если вы хотите читать/писать туда. По сути, это будет похоже на бесшовный режим, описанный выше, но с собственным отдельным рабочим каталогом.
3. Полностью изолированный (ненадежный) режим: у контейнера будет свой собственный отдельный пользовательский и домашний каталог, без абсолютного доступа к домашнему каталогу пользователя вашего хоста. Это было бы полезно для запуска ненадежного программного обеспечения, которому вы не хотите позволять читать все в вашем домашнем каталоге.

Это звучит очень разумно для меня. Как вы думаете, @debarshiray??

Я поддерживаю это @JaneSmith , все, что мне нужно - красиво сказано!

Я тоже поддерживаю идею. Но пока он не будет реализован, вы можете использовать direnv . Это удобный инструмент, который позволяет указывать переменные среды для каждого каталога. Вы можете использовать следующий рабочий процесс

- 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

теперь каждый раз, когда вы входите в каталог somedev , он будет предполагать, что это домашний каталог, и сбрасывается, когда вы выходите из него. Вы можете выполнить все шаги после установки direnv одной командой, например:

``` баш
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
В настоящее время я использую аналогичный рабочий процесс.

Я согласен, что должна быть хотя бы возможность не монтировать домашний каталог (ссылка https://github.com/containers/toolbox/issues/183#issuecomment-623103780). На самом деле, я был бы даже в порядке, если бы он использовал — подобно flatpak — какой-то каталог в ~/.var/app , может быть, лучше ~/.var/toolbox или около того, где все файлы в домашнем каталоге сохраняются по умолчанию.
Мне очень нравится эта модель flatpak, потому что у вас есть все данные из одного контейнера в одном месте, и если вы удалите контейнер, вы также можете удалить все данные приложения. (или просто измерьте пространство, которое занял ваш новый проект «Я попробовал ржавчину»), например (как это делается в gnome-control-center)

Затем, для удобства, он, возможно, всегда должен монтироваться в текущий $PWD, если вы запускаете его из папки проекта, вы, вероятно, ожидаете, что файлы будут там. Просто вашей папке ~/rust-project не нужен доступ к ~/Pictures/private/… и т. д.

В любом случае, конечно, нужно иметь возможность монтировать home только для чтения или даже для записи, но я не думаю, что это действительно необходимо для большинства приложений.
И нужно уметь не монтировать текущую $PWD .

Таким образом, у вас будет «золотая середина» в качестве нового значения по умолчанию.

У форка tlbx есть опция -n , позволяющая не привязывать домашний каталог.

Дубликат https://github.com/containers/toolbox/issues/183

Нееет… у вас все еще могут быть другие варианты использования/причины использования другого $HOME, чем «Изолированные среды разработки для защиты от ошибок и вредоносных программ в разрабатываемом коде»…

ИМХО, это все еще функция, которую должен иметь инструментарий.

Я не понимаю, почему этот вопрос был закрыт. Это не дубликат этого. Это касается не только безопасности. Я очень надеюсь, что это будет пересмотрено, так как мне нравится Fedora Silverblue и нравится, что в нем есть встроенный инструмент для настройки контейнеров для домашних животных, но в настоящее время он не выполняет свою работу. Я не хочу использовать форк только для этого... Я использую набор инструментов для домашних контейнеров для работы с различными программными проектами, и я не хочу, чтобы мой домашний каталог был загроможден контейнерами. Это не имеет ничего общего с безопасностью.

@JaneSmith, почему бы не использовать форк, если у него есть нужные вам функции?

Я бы предпочел использовать Toolbox, а не форк, потому что Toolbox лучше поддерживается большим количеством разработчиков и входит в состав Fedora из коробки. Когда я перехожу с машины на машину, Toolbox уже там, и мне не нужно устанавливать вилки. Одна из причин использования Toolbox в первую очередь заключается в том, чтобы не загромождать мою систему случайными установками программного обеспечения!

По моему скромному мнению, этот запрос функции предназначен для чего-то, что должно быть основной, базовой функциональностью, поскольку ее отсутствие как бы противоречит цели Toolbox. Я не считаю это чем-то действительно необычным. Поэтому я выражаю свою поддержку этому и надеюсь, что он будет реализован для этого проекта.

@JaneSmith Я согласен по всем пунктам. Я ожидаю, что эта функция будет реализована в первый раз, когда текущий небезопасный дизайн будет опубликован, чтобы сыграть роль в нарушении безопасности, если не раньше.

В первом предложении в документах говорится, что он работает _полностью непривилегированным _. Звучит надежно, да?

Также в основном описании: _Намерение этих систем состоит в том, чтобы препятствовать установке программного обеспечения на хосте и вместо этого устанавливать программное обеспечение в виде (или в) контейнерах._ Также звучит так, как будто этот проект должен обеспечить значительную безопасность.

Нигде в документах не подчеркивается, что он делится каждым документом, которым владеет ваш пользователь, с каждым контейнером, включая ключи SSH и файлы, не связанные с тем, что происходит в контейнере.

Текущая ситуация не только небезопасна, но и вводит в заблуждение, что использование контейнеров, подобных этому, обеспечивает значительную безопасность, когда контейнеры вряд ли могут получить доступ ко всем вашим файлам!

Если вы ищете «дом» в README, нет документации, что ваш домашний каталог используется таким образом.

Я тоже этого хочу. Средний уровень (дом доступен, но не определяется как ДОМ) и более ненадежный режим (дом вообще недоступен).

Обычно я просто делаю HOME=/home/user1/container1 перед созданием контейнеров и просто использую псевдоним для их открытия. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Если среднее решение так просто... то почему его нельзя внедрить в Toolbox в качестве опции? Просто возьмите домашний путь в качестве аргумента при создании набора инструментов и сохраните его где-нибудь, возможно, так же, как сохраняется имя контейнера. Затем прочитайте этот путь и установите его при входе в контейнер...

Чтобы сделать вещи немного более конкретными:

• --new-home , что сообщит тулбоксу, чтобы он не монтировал хост $HOME (или монтировал его где-то еще в контейнере, который не является $HOME)
• --from-home path1:path2:pathN , который укажет набору инструментов для монтирования определенных путей от хоста $HOME до дома контейнера.

Так, например, если у меня есть исходные каталоги в ~/Projects, мне нужно подписывать вещи с помощью gpg и мне нужен ssh для подключения к серверу и моя конфигурация git, я мог бы создать такой набор инструментов:

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

Так это что-то будет принято выше по течению? Я бы даже поработал над этим, если план имеет смысл.