Toolbox: 홈 경로 조정

나는 일반적으로 컨테이너를 생성하기 전에 HOME=/home/user1/container1 를 수행하고 별칭을 사용하여 컨테이너를 엽니다. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

예, $HOME 를 재정의하는 것이 한 가지 방법입니다.

저도 이런거 보고싶습니다. Toolbox의 주요 사용 사례는 프로젝트에서 작업하거나 소스에서 일부 소프트웨어를 빠르게 컴파일하기 위해 일회용 개발 환경을 설정하는 것입니다. 한 번만 컴파일하기 위해 종속성 등의 임의 파일로 시스템을 오염시키고 싶지 않습니다. Toolbox는 호스트를 깨끗하게 유지하기 위해 격리된 컨테이너를 제공한다고 주장하므로 이에 완벽해 보였습니다.

이것은 내가 예상한 대로 작동하지 않는 것으로 밝혀졌습니다. Toolbox 는 호스트 OS를 깨끗하게 유지하지만 홈 디렉토리를 전혀 깨끗하게 유지하지는 않습니다. 그것은 여전히 ​​완전히 오염됩니다. 예를 들어, rust 를 사용하는 무언가를 빌드하기 위해 일회용 컨테이너를 사용하면 내 홈 디렉토리가 여러 방식으로 변경되었습니다.

• ~/.cargo 디렉토리는 총 123MB에 대해 많은 Rust 관련 바이너리, 소스 패키지 등을 포함하여 자동으로 생성되었습니다.
• ~/.rustup 디렉토리는 더 많은 Rust 관련 바이너리를 포함하여 총 683MB에 ​​자동으로 생성되었습니다.
• 내 ~/.bash_profile 파일은 ~/.cargo/bin 디렉토리를 다른 모든 것보다 먼저 $PATH에 추가하도록 자동으로 변경되었습니다.
• 내 ~/.profile 파일은 ~/.cargo/bin 디렉토리를 다른 모든 것보다 먼저 $PATH에 추가하도록 자동으로 변경되었습니다.
• 누가 또 뭘 알겠어.

그렇군요. 일시적이고 폐기하기 쉬운 시스템으로 여겨졌던 것이 내 홈 디렉토리에 많은 영구적인 변경 사항이 자동으로 만들어지는 결과를 가져왔습니다. 위의 설명을 통해 이 문제를 해결하기 위해 수동으로 $HOME 환경 변수를 재정의할 수 있음을 깨달았지만 이것은 직관적이거나 예상하지 못했습니다. Toolbox는 컨테이너에 들어가는 단순화되고 사용자 친화적인 방법(또는 적어도 내가 이해하는 한)이어야 하기 때문에 이것이 더 나은 방식으로 처리될 수 있다면 감사하겠습니다.

내 생각에 Toolbox에는 기본적으로 고유한 사용자와 홈 디렉토리가 있어야 합니다. 그러나 이것이 구현하기에 너무 복잡하다면 새 도구 상자를 생성할 때 기본 $HOME을 설정하기 위해 최소한 -h 또는 --home 인수가 있을 수 있습니다. 나중에 도구 상자에 들어갈 때 $HOME 값이 자동으로 설정되도록 합니다. 예를 들어, toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject 행을 따르는 것입니다.

기본적으로 Toolbox에 세 가지 모드 중 하나로 컨테이너를 설정할 수 있는 사용자 친화적인 방법이 있으면 좋을 것 같습니다.

1. 심리스 모드: 현재 작동 방식. 컨테이너 사용자는 실제 호스트 사용자인 것처럼 작동하여 홈 디렉토리를 공유합니다.
2. 반 격리 모드: 컨테이너는 호스트 사용자의 파일에 액세스할 수 있지만 기본적으로 소프트웨어에서 사용할 수 있는 자체 홈 디렉터리가 있습니다. 거기에 읽기/쓰기를 하려면 호스트 사용자의 홈 디렉토리에 수동으로 액세스해야 합니다. 기본적으로 위의 Seamless 모드와 같지만 별도의 작업 디렉터리가 있습니다.
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 && 에코 내보내기 홈=/home/user/somedev > ~/somedev/.envrc
````
현재 비슷한 작업 흐름을 사용하고 있습니다.

적어도 홈 디렉토리를 마운트하지 않는 옵션이 있어야 한다는 데 동의합니다(https://github.com/containers/toolbox/issues/183#issuecomment-623103780 참조). 사실, flatpak과 유사하게 - some dir in ~/.var/app , 아마도 더 나은 ~/.var/toolbox 정도를 사용하면 괜찮을 것입니다. 여기서 홈 디렉토리의 모든 파일은 기본적으로 저장됩니다.
한 컨테이너의 모든 데이터가 한 곳에 있고 컨테이너를 삭제하면 모든 앱 데이터도 삭제할 수 있기 때문에 저는 그 플랫팩 모델을 아주 좋아합니다. (또는 새로운 "나는 녹을 시도했습니다" 프로젝트가 차지한 공간을 측정하십시오), 예를 들어 (gnome-control-center에서 수행된 것처럼)

그런 다음 편의를 위해 항상 현재 $PWD에 마운트해야 합니다. 프로젝트 폴더에서 시작하면 거기에 파일이 있을 것으로 예상할 수 있습니다. ~/rust-project 폴더는 ~/Pictures/private/… 등에 액세스할 필요가 없습니다.

어쨌든, 물론 선택적으로 홈을 읽기 전용 또는 쓰기 가능으로 마운트할 수 있어야 하지만 대부분의 응용 프로그램에는 이것이 실제로 필요하지 않다고 생각합니다.
그리고 현재 $PWD 를 마운트할 수 없어야 합니다.

따라서 여기에 새로운 기본값으로 "중간"이 있습니다.

tlbx 포크에는 홈 디렉토리를 바인드 마운트하지 않는 -n 옵션이 있습니다.

https://github.com/containers/toolbox/issues/183 의 복제본

아니요... "개발 중인 코드의 버그 및 맬웨어를 방지하기 위한 격리된 개발 환경"과 다른 $HOME을 사용하는 다른 사용 사례/이유가 있을 수 있습니다.

IMHO, 이것은 여전히 ​​도구 상자에 있어야 하는 기능입니다.

이 문제가 왜 종료되었는지 이해가 되지 않습니다. 그 복제품이 아닙니다. 이것은 단지 보안에 관한 것이 아닙니다. 나는 Fedora Silverblue를 사랑하고 애완 동물 컨테이너를 설정하는 도구가 내장되어 있다는 점을 좋아하기 때문에 이것이 재고되기를 정말로 희망하지만 현재 실제로 작동하지 않습니다. 나는 그것을 위해 포크를 사용하고 싶지 않습니다 ... 나는 애완 동물 컨테이너 용 도구 상자를 사용하여 다양한 프로그래밍 프로젝트를 처리하고 내 홈 디렉토리가 컨테이너로 인해 어수선해지는 것을 원하지 않습니다. 보안과 관련이 없습니다.

@JaneSmith 필요한 기능이 있다면 포크를 사용하지 않으시겠습니까?

Toolbox는 더 많은 개발자가 지원하고 Fedora에 즉시 포함되어 있기 때문에 포크보다는 Toolbox를 사용하는 것을 선호합니다. 기계에서 기계로 이동할 때 포크를 설치할 필요 없이 Toolbox가 이미 있습니다. 처음에 Toolbox를 사용하는 이유 중 하나는 무작위 소프트웨어 설치로 시스템이 복잡해지는 것을 방지하기 위해서입니다!

내 겸손한 생각에 이 기능 요청은 Toolbox의 목적에 어긋나는 종류가 없기 때문에 핵심적인 기본 기능이어야 하는 것입니다. 나는 그것을 정말로 "밖에서" 특이한 특수 기능으로 보지 않습니다. 따라서 저는 이에 대한 지지를 표명하고 있으며 이 프로젝트를 위해 구현되기를 희망합니다.

@JaneSmith 모든 요점에 동의합니다. 나는 현재의 안전하지 않은 디자인이 보안 침해에 관여하기 위해 처음으로 공개될 때 이 기능이 구현될 것으로 기대합니다.

문서의 첫 번째 문장은 _완전히 권한이 없는 _을 실행한다고 말합니다. 안전한 것 같죠?

또한 주요 설명에서: _이 시스템의 의도는 호스트에 소프트웨어 설치를 권장하지 않고 대신 소프트웨어를 컨테이너로(또는 안에) 설치하는 것입니다._ 또한 이 프로젝트는 상당한 보안을 추가해야 하는 것처럼 들립니다.

문서에서는 컨테이너에서 일어나는 일과 관련 없는 SSH 키 및 파일을 포함하여 사용자가 소유한 모든 문서를 모든 컨테이너와 공유한다는 점을 강조하지 않습니다.

현재 상황은 안전하지 않을 뿐만 아니라 컨테이너가 모든 파일에 액세스할 수 있는 경우가 거의 없는 경우 이와 같은 컨테이너를 사용하면 상당한 보안을 제공한다는 오해를 불러일으킵니다!

README에서 "home"을 검색하면 홈 디렉토리가 이런 방식으로 공유된다는 문서가 없습니다.

나도 이것을 원한다. 중간 지점(집에 접근할 수 있지만 HOME으로 정의되지 않음)과 더 신뢰할 수 없는 모드(집에 전혀 접근할 수 없음).

나는 일반적으로 컨테이너를 생성하기 전에 HOME=/home/user1/container1 를 수행하고 별칭을 사용하여 컨테이너를 엽니다. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

중간 솔루션이 이렇게 간단하다면... 도구 상자에 옵션으로 구현할 수 없는 이유는 무엇입니까? 도구 상자를 만들 때 홈 경로를 인수로 가져 와서 어딘가에 저장하십시오. 아마도 컨테이너 이름이 저장되는 방식과 같을 것입니다. 그런 다음 해당 경로를 읽고 컨테이너에 들어갈 때 설정하십시오 ...

좀 더 구체적으로 만들려면:

• --new-home 이는 toolbox enter에게 호스트 $HOME을 마운트하지 않도록 지시합니다(또는 $HOME이 아닌 컨테이너의 다른 위치에 마운트)
• --from-home path1:path2:pathN 이것은 호스트 $HOME에서 컨테이너 홈으로의 특정 경로를 마운트하도록 도구 상자에 입력하도록 지시합니다.

예를 들어 ~/Projects에 소스 디렉토리가 있는 경우 gpg로 서명해야 하고 서버에 연결하기 위해 ssh가 필요하고 git config에서 다음과 같은 도구 상자를 만들 수 있습니다.

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

그래서 이것은 업스트림에서 받아들여질 것입니까? 계획이 타당하다면 이 작업을 수행할 것입니다.