Mount SSHFS milik pengguna, bukan kait VPN

Asumsinya mudah diserap dan sulit disadari: kait koneksi VPN berjalan sebagai root, jadi mount yang dimulainya juga harus diatur sebagai root. Penalaran itu menghasilkan direktori tim yang tidak bisa dibuka pengguna desktop, mount yang hilang saat layanan pemicu dimulai ulang, dan permintaan autentikasi dalam konteks yang tidak bisa dijawab siapa pun. Kait dan mount adalah dua pekerjaan berbeda, dan hanya salah satunya membutuhkan hak istimewa.

Mitos: hak istimewa jaringan berarti hak istimewa mount

Menaikkan antarmuka dan mengautentikasi ke server berkas adalah kemampuan yang tidak saling terkait, dan biasanya milik akun berbeda. Komponen VPN membutuhkan hak istimewa yang cukup untuk mengubah rute dan antarmuka. Akun server berkas membutuhkan kunci atau kata sandi, keputusan tentang kunci host, dan direktori rumah untuk di-mount. Menyerahkan kredensial pekerjaan kedua ke identitas pertama adalah cara sebuah layanan jaringan akhirnya memegang kunci pengguna.

Pada laptop satu pengguna keduanya bisa menjadi akun yang sama, dan kebetulan itu bukan desain.

Setelah kait berhak istimewa melakukan mount, tiga hal salah secara diam-diam. Mount dimiliki root, agen pengguna tidak ada di lingkungan itu, dan kegagalan muncul di log layanan jaringan alih-alih di sesi yang peduli. Tidak satu pun dari itu diperbaiki dengan menambahkan opsi ke perintah mount. Semuanya diperbaiki dengan menyerahkan pekerjaan itu ke sesi yang memiliki identitas.

Mengapa mount milik pengguna yang sudah login

Mount SSHFS adalah mount FUSE yang dimiliki proses yang membuatnya, dan akses mengikuti kepemilikan itu, bukan mode direktori induknya. Referensi merekomendasikan pengguna biasa dengan titik mount yang dimiliki pengguna itu, dan itulah tepatnya alasan mount yang dibuat proses root merepotkan bagi semua orang lain. Perubahan izin pada titik mount tidak memperbaikinya, karena penghalangnya adalah pemilik mount itu sendiri.

Mulailah dari garis dasar manual di dalam sesi pengguna: titik mount kosong yang sudah ada di bawah direktori rumah, akun yang diotorisasi di server, dan kunci host yang sudah diverifikasi melalui proses Anda yang disetujui. Mount secara manual sekali dan gunakan, karena itu membuktikan jalur identitas bekerja sebelum ada otomatisasi apa pun. Catat apa yang dibutuhkan perintah: nama akun, jalur ekspor, dan nama host privat. Simpan konteks persis itu untuk versi otomatis, karena mount manual yang berfungsi adalah spesifikasi yang harus direproduksi pemicu.

sshfs [email protected]:/exports/team "$HOME/mnt/team"

Perlakukan setiap nama dan jalur di baris itu sebagai placeholder, termasuk akun dan ekspornya. Kata sandi akun VPN tidak otomatis menjadi kredensial akun penyimpanan.

Apa yang harus diminta pemicu kepada sesi

Pengaturan yang didukung adalah permintaan dari peristiwa jaringan ke sesi pengguna, bukan kredensial pinjaman. Batasi pemicu ke koneksi yang dimaksud, berdasarkan nama atau UUID, bukan ke antarmuka apa pun yang kebetulan bernama tun0. Perubahan tunggal itu menghentikan profil kedua, terowongan uji, atau sesi debug rekan kerja memulai mount.

Tindakan di sisi sesi harus mencari mount yang ada dan dimaksudkan, lalu melakukan satu upaya terbatas.

Jangan mencoba ulang pada setiap polling, dan jangan terus meminta kredensial saat server tidak dapat dijangkau, karena keduanya mengubah gangguan sementara menjadi penguncian akun. Layanan tanpa pengawasan adalah desain terpisah dengan kredensial disetujui dan pengaturan verifikasi host sendiri dalam konteks eksekusinya sendiri, dan tidak bisa mengandalkan seseorang telah membuka agen grafis. Putuskan mana dari keduanya yang Anda bangun sebelum memilih di mana kode tinggal. Sebagian besar kebingungan di sini berasal dari membangun yang satu dan mengharapkan yang lain.

Pemutusan koneksi adalah peristiwa sistem berkas, bukan peristiwa kait

Pemutusan terencana harus menyelesaikan operasi berkas dan melepas mount dari sesi pengguna yang me-mount dengan perintah yang didukung untuk jenis sistem berkas itu. Memaksa pelepasan agar kait cepat kembali adalah cara aplikasi kehilangan direktori kerja dan pengguna kehilangan kepercayaan pada otomatisasi. Mount yang sibuk membutuhkan keputusan tingkat aplikasi, seperti menutup berkas atau menghentikan penulisan, bukan sinyal yang lebih kuat. Status keluar kait bukan hal yang dioptimalkan.

fusermount3 -u "$HOME/mnt/team"

Kehilangan tak terduga adalah kasus berbeda, dan SSHFS mendokumentasikan bahwa operasi yang terputus dapat memblokir saat transport menghubungkan ulang.

Opsi sambung ulang memulihkan transport, dan berkas yang dibuka sebelum sambung ulang itu masih bisa mengembalikan galat dan perlu dibuka lagi. VPN yang kembali tidak membuktikan apa pun tentang handle sebelumnya atau pekerjaan yang belum disimpan. Pilih perilaku yang Anda inginkan saat gangguan — menjeda, menampilkan galat, atau me-mount ulang dengan sengaja — dan ujilah dengan berkas sekali pakai sebelum apa pun bergantung padanya.