Toolbox: Sesuaikan jalur rumah

Saya biasanya hanya melakukan HOME=/home/user1/container1 sebelum membuat wadah dan hanya menggunakan alias untuk membukanya. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Ya, mengganti $HOME adalah salah satu cara untuk melakukannya.

Saya juga ingin melihat sesuatu seperti ini. Kasus penggunaan utama saya untuk Toolbox adalah untuk mengatur lingkungan pengembangan sekali pakai, baik untuk mengerjakan proyek, atau hanya dengan cepat mengkompilasi beberapa perangkat lunak dari sumber. Saya tidak ingin mengotori sistem saya dengan file acak dari dependensi, dll. hanya untuk mengkompilasi sesuatu sekali. Toolbox tampak sempurna untuk ini, karena mengklaim menyediakan wadah terisolasi untuk menjaga host tetap bersih.

Ini ternyata tidak bekerja seperti yang saya harapkan. Meskipun Toolbox menjaga OS host tetap bersih, itu tidak menjaga direktori home tetap bersih sama sekali. Itu masih benar-benar tercemar. Misalnya, menggunakan wadah sekali pakai untuk membangun sesuatu yang menggunakan rust , direktori home saya akhirnya diubah dalam beberapa cara:

• Direktori ~/.cargo dibuat secara diam-diam, berisi banyak binari terkait Rust, paket sumber, dll. dengan total 123 MB.
• Direktori ~/.rustup dibuat secara diam-diam, berisi lebih banyak binari terkait Rust, dengan total 683 MB.
• File ~/.bash_profile saya diam-diam diubah untuk menambahkan direktori ~/.cargo/bin ke $PATH saya sebelum yang lainnya.
• File ~/.profile saya diam-diam diubah untuk menambahkan direktori ~/.cargo/bin ke $PATH saya sebelum yang lainnya.
• Siapa yang tahu apa lagi.

Astaga. Apa yang seharusnya menjadi sistem sementara, sekali pakai, mudah dibuang menghasilkan banyak perubahan permanen yang diam-diam dibuat ke direktori home saya. Saya menyadari sekarang dari komentar di atas bahwa saya dapat mengganti variabel lingkungan $HOME secara manual untuk mencoba mengatasi ini, tetapi ini tidak intuitif atau diharapkan bagi saya. Karena Toolbox seharusnya (atau setidaknya seperti yang saya pahami) cara yang disederhanakan dan ramah pengguna untuk masuk ke wadah, saya akan menghargai jika ini dapat ditangani dengan cara yang lebih baik.

Pendapat saya adalah bahwa Toolbox mungkin harus memiliki pengguna dan direktori home uniknya sendiri secara default. Tetapi jika ini terlalu rumit untuk diterapkan, maka mungkin setidaknya ada argumen -h atau --home saat membuat kotak alat baru, untuk menyetel default $HOME? Sehingga ketika Anda memasuki kotak alat di masa depan, itu akan mendapatkan nilai $HOME yang disetel secara otomatis. Misalnya, sesuatu di sepanjang baris toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

Pada dasarnya, saya pikir akan sangat bagus jika Toolbox memiliki cara yang mudah digunakan untuk menyiapkan wadah di salah satu dari tiga mode:

1. Mode mulus: Cara kerjanya sekarang. Pengguna kontainer bertindak seolah-olah itu adalah pengguna host Anda yang sebenarnya, berbagi direktori home Anda.
2. Mode semi-terisolasi: Wadah memiliki akses ke file pengguna host Anda, tetapi memiliki direktori home sendiri untuk perangkat lunak untuk digunakan secara default. Anda perlu mengakses direktori home pengguna host Anda secara manual jika Anda ingin membaca/menulis di sana. Ini pada dasarnya akan seperti mode Seamless di atas, tetapi dengan direktori kerjanya sendiri yang terpisah.
3. Mode yang sepenuhnya terisolasi (tidak dipercaya): Wadah akan memiliki pengguna dan direktori home sendiri yang terpisah, tanpa akses sama sekali ke direktori home pengguna host Anda. Ini akan berguna untuk menjalankan perangkat lunak yang tidak tepercaya, yang tidak boleh Anda izinkan untuk membaca semua yang ada di direktori home Anda.

Ini terdengar sangat masuk akal bagi saya. Bagaimana menurut Anda @debarshiray??

Saya mendukung @JaneSmith ini, semua yang saya butuhkan - dengan baik!

Saya juga mendukung ide tersebut. Tetapi sampai diimplementasikan, Anda bisa menggunakan direnv . Ini adalah alat yang berguna yang memungkinkan seseorang untuk menentukan variabel lingkungan pada basis per direktori. Anda dapat menggunakan alur kerja berikut:

- 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

sekarang setiap kali Anda masuk ke direktori somedev itu akan menganggap itu adalah direktori home dan me-reset ketika Anda keluar darinya. Anda dapat melakukan semua langkah setelah menginstal direnv dalam satu perintah seperti:

``` bash
mkdir ~/somedev && echo export HOME=/home/user/somedev > ~/somedev/.envrc
````
Saat ini saya menggunakan alur kerja yang serupa.

Saya setuju setidaknya harus ada opsi untuk tidak memasang direktori home (ref https://github.com/containers/toolbox/issues/183#issuecomment-623103780). Sebenarnya, saya akan baik-baik saja jika menggunakan – mirip dengan flatpak – beberapa dir di ~/.var/app , mungkin lebih baik ~/.var/toolbox atau lebih, di mana semua file di direktori home disimpan secara default.
Saya cukup menyukai model flatpak itu, karena Anda memiliki semua data dari satu wadah di satu tempat, dan jika Anda menghapus wadah, Anda juga dapat menghapus semua data aplikasi. (atau cukup ukur ruang yang digunakan proyek "Saya sudah mencoba karat" baru Anda), misalnya (seperti yang dilakukan di gnome-control-center)

Kemudian, untuk kenyamanan, mungkin harus selalu dipasang di $PWD saat ini, jika Anda memulainya dari folder proyek, Anda mungkin berharap memiliki file di sana. Hanya, folder ~/rust-project Anda, tidak memerlukan akses apa pun ke ~/Pictures/private/… dll.

Bagaimanapun, tentu saja seseorang harus dapat me-mount rumah secara opsional sebagai hanya-baca atau bahkan dapat ditulis, tetapi saya tidak berpikir itu benar-benar diperlukan untuk sebagian besar aplikasi.
Dan seseorang seharusnya tidak dapat memasang $PWD saat ini.

Jadi Anda akan memiliki "jalan tengah" di sini sebagai default baru.

tlbx fork memiliki opsi -n untuk tidak mengikat-mount direktori home.

Duplikat https://github.com/containers/toolbox/issues/183

Tidaaak… Anda masih dapat memiliki kasus/alasan penggunaan lain untuk memiliki $HOME yang berbeda dengan "Lingkungan pengembangan yang terisolasi untuk melawan bug dan malware dalam kode yang sedang dikembangkan"…

IMHO, ini masih merupakan fitur yang seharusnya dimiliki oleh kotak peralatan.

Saya tidak mengerti mengapa masalah ini ditutup. Itu bukan duplikatnya. Ini bukan hanya tentang keamanan. Saya sangat berharap ini akan dipertimbangkan kembali karena saya menyukai Fedora Silverblue dan suka bahwa ia memiliki alat bawaan untuk menyiapkan wadah hewan peliharaan, tetapi itu tidak benar-benar berfungsi saat ini. Saya tidak ingin harus menggunakan garpu hanya untuk itu... Saya menggunakan kotak peralatan untuk wadah hewan peliharaan untuk menangani berbagai proyek pemrograman, dan saya tidak ingin direktori home saya dikotori oleh wadah. Ini tidak ada hubungannya dengan keamanan.

@JaneSmith mengapa tidak menggunakan garpu jika memiliki fitur yang Anda butuhkan?

Saya lebih suka menggunakan Toolbox daripada garpu, karena Toolbox lebih baik didukung dengan lebih banyak pengembang, dan disertakan dengan Fedora di luar kotak. Saat saya berpindah dari mesin ke mesin, Toolbox sudah ada, tanpa saya harus memasang garpu. Bagian dari alasan menggunakan Toolbox adalah untuk menghindari sistem saya yang berantakan dengan instalasi perangkat lunak acak!

Menurut pendapat saya yang sederhana, permintaan fitur ini adalah untuk sesuatu yang harus menjadi inti, fungsionalitas dasar, karena tidak memilikinya akan mengalahkan tujuan Toolbox. Saya tidak melihatnya sebagai fitur khusus yang benar-benar "di luar sana". Oleh karena itu saya menyuarakan dukungan saya untuk itu dan berharap itu akan diterapkan untuk proyek ini.

@JaneSmith saya setuju pada semua poin. Saya berharap fitur ini akan diimplementasikan pertama kali desain tidak aman saat ini dipublikasikan untuk berperan dalam pelanggaran keamanan, jika tidak lebih cepat.

Kalimat pertama dalam dokumen mengatakan itu berjalan _sepenuhnya tidak memiliki hak _. Kedengarannya aman, ya?

Juga dalam deskripsi utama: _Tujuan dari sistem ini adalah untuk mencegah penginstalan perangkat lunak pada host, dan sebagai gantinya menginstal perangkat lunak sebagai (atau dalam) wadah._ Sepertinya proyek ini juga harus menambahkan keamanan yang signifikan.

Dokumen tidak menyoroti bahwa itu berbagi setiap dokumen yang dimiliki pengguna Anda dengan setiap wadah, termasuk kunci SSH dan file yang tidak terkait dengan apa yang terjadi di wadah.

Situasi saat ini tidak hanya tidak aman, tetapi menyesatkan untuk menyampaikan bahwa menggunakan wadah seperti ini memberikan keamanan yang signifikan, ketika wadah tidak dapat mengakses semua file Anda!

Jika Anda mencari "home" di README, tidak ada dokumentasi bahwa direktori home Anda dibagikan dengan cara ini.

Saya ingin ini juga. Jalan tengah (dapat diakses di rumah, tetapi tidak didefinisikan sebagai RUMAH), dan mode yang lebih tidak tepercaya (rumah tidak dapat diakses sama sekali).

Saya biasanya hanya melakukan HOME=/home/user1/container1 sebelum membuat wadah dan hanya menggunakan alias untuk membukanya. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

Jika solusi jalan tengah sesederhana ini ... lalu mengapa itu tidak dapat diimplementasikan ke dalam Toolbox sebagai opsi? Ambil saja jalur beranda sebagai argumen saat membuat kotak alat dan simpan di suatu tempat, mungkin dengan cara yang sama seperti cara nama wadah disimpan. Kemudian baca jalur itu dan atur saat memasuki wadah ...

Untuk membuat segalanya sedikit lebih konkret:

• --new-home yang akan memberi tahu kotak alat masuk untuk tidak memasang Host $HOME (atau memasangnya di tempat lain dalam wadah yang bukan $HOME)
• --from-home path1:path2:pathN yang akan memberi tahu kotak alat masuk untuk memasang jalur tertentu dari Host $HOME ke rumah kontainer

Jadi misalnya jika saya memiliki direktori sumber di ~/Projects, perlu menandatangani sesuatu dengan gpg dan perlu ssh untuk terhubung ke server dan konfigurasi git saya, saya dapat membuat kotak alat seperti ini:

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

Jadi apakah ini sesuatu yang akan diterima di hulu? Saya bahkan akan mengerjakan ini jika rencananya masuk akal.