Temu Duga Linux: Bagaimanakah Bekas Mengasingkan Proses dan Sumber?

Gesaan dan Konteks Berkenaan

Pada hos Linux yang menggunakan cgroup v2, bekas A mempunyai kekangan latihan ini:

Di dalam bekas, aplikasi melihat dirinya sebagai PID 1, hostname bekas, jadual lekapannya sendiri, dan antara muka rangkaiannya sendiri. Terangkan cara runtime mencipta persekitaran itu, dari mana pengasingan sebenarnya datang, dan bagaimana kegagalan had kelihatan. Kemudian rangkumkan sempadan keselamatan kernel dikongsi dan buktikan konfigurasi tersebut dengan keadaan kernel yang boleh diperhatikan dan bukannya docker run yang berjaya semata-mata.

Soalan ini terpakai untuk peranan Linux, platform, SRE, DevOps, infrastruktur, awan, keselamatan, dan bahagian belakang (backend). Nilai-nilai ini ialah kekangan temu duga, bukan lalai yang disyorkan. “Bekas” merujuk kepada bekas proses gaya OCI Linux; produk bekas bersandarkan VM menambah lapisan pengasingan yang berbeza.

Perkara yang Dinilai oleh Penemu Duga

Ujian pertama ialah sama ada calon boleh menggantikan frasa “VM ringan” dengan model proses yang tepat. Bekas Linux ialah pepohon proses pada hos. Namespace mengubah sumber global yang boleh dilihat oleh proses tersebut: PID, lekapan, objek rangkaian, objek IPC, identiti hos, ID pengguna, laluan cgroup, dan secara pilihan jam. Sistem fail punca dan paparan lekapan peribadi membekalkan imej ruang pengguna. Tiada satu pun daripadanya yang mencipta kernel kedua.

Ujian kedua ialah memisahkan keterlihatan daripada kawalan sumber. Namespace menjawab “kejadian manakah yang boleh diperhatikan atau diubah suai oleh proses ini?” Cgroups menjawab “berapa banyak yang boleh digunakan oleh kumpulan ini, dan bagaimanakah ia diakaunkan?” Namespace PID tidak mengehadkan bilangan tugasan. Had PID cgroup tidak menyembunyikan proses hos. Namespace lekapan mengubah paparan lekapan, manakala rootfs membekalkan fail. chroot semata-mata bukanlah bekas yang lengkap mahupun sempadan keselamatan.

Ujian ketiga ialah menerbitkan tingkah laku daripada fail cgroup v2 yang tepat. memory.max ialah sempadan memori tegar yang boleh membawa kepada pembunuhan OOM setempat cgroup selepas penuntut semula (reclaim) gagal. cpu.max ialah kawalan lebar jalur: selepas menggunakan 50 ms dalam tempoh 100 ms, kerja yang boleh dijalankan akan dicekik (throttled) sehingga kuota tersedia; ia tidak dimatikan. pids.max menolak fork() atau clone() yang melanggar dengan EAGAIN. Calon harus menamakan pembilang peristiwa yang membezakan hasil ini.

Ujian keempat ialah pertimbangan keselamatan. Bekas berkongsi kernel hos, jadi namespace dan cgroups tidak bersamaan dengan sempadan VM. Pemetaan ID pengguna, set keupayaan yang kecil, no_new_privs, seccomp, LSM seperti AppArmor atau SELinux, lekapan baca sahaja atau bertopeng, dan peranti terhad mengurangkan permukaan serangan. Bekas istimewa (privileged), namespace PID atau rangkaian hos, soket Docker, atau lekapan hos yang luas boleh menanggalkan sempadan penting secara sengaja.

Akhir sekali, penemu duga mahukan pelan pengesahan. Jawapan harus membandingkan identiti inode namespace, pemetaan UID/GID, keahlian cgroup dan fail pengawal, keupayaan proses, keadaan seccomp, perambatan lekapan, antara muka rangkaian, dan pembilang kegagalan daripada kedua-dua belah sempadan.

Soalan untuk Dijelaskan Sebelum Menjawab

• Runtime dan mod bekas manakah yang berada dalam skop? Runtime OCI pada Linux diandaikan. Mod tanpa punca (rootless), pemetaan semula user namespace, mod istimewa, dan kotak pasir bersandarkan VM mengubah sempadan kepercayaan.
• Adakah “0.5 CPU” bermaksud kuota atau pemberat relatif? Di sini ia bermaksud had lebar jalur sebanyak 50,000 mikrosaat bagi setiap tempoh 100,000 mikrosaat. cpu.weight hanya mengubah bahagian relatif semasa perbalahan (contention).
• Apakah yang disertakan oleh 512 MiB? cgroup v2 mengakaunkan pengguna utama seperti memori tanpa nama (anonymous memory), cache halaman, struktur kernel, dan penimbal soket, tetapi bukan setiap sumber hos dikawal oleh fail tunggal ini.
• Adakah 128 bermaksud proses atau tugasan kernel? Pengawal pids menggunakan ID tugasan kernel, jadi bebenang (threads) juga menggunakan belanjawan tersebut. Butiran itu penting untuk runtime yang banyak menggunakan bebenang.
• Adakah swap didayakan dan dihadkan secara berasingan? memory.max dan memory.swap.max ialah kawalan yang berbeza. Gesaan ini hanya menetapkan had memori, jadi dasar swap mesti diperiksa dan bukannya diandaikan.
• Namespace manakah yang sebenarnya dikonfigurasikan? Konfigurasi OCI boleh mencipta namespace, menyertai namespace sedia ada melalui laluan, atau mengabaikan jenis tersebut dan mewarisi namespace runtime. Ketiadaan satu namespace merupakan perubahan sempadan yang sebenar.
• Apakah model ancamannya? Beban kerja berbilang penyewa yang bermusuhan mungkin memerlukan sempadan VM atau microVM selain daripada pengasingan proses. Beban kerja dalaman yang dipercayai mungkin menerima keseimbangan yang berbeza.

Rangka Kerja Jawapan 30 Saat

“Bekas Linux ialah pepohon proses hos yang dimulakan terhadap rootfs, diletakkan dalam namespace terpilih dan cgroup; kernel hos kekal dikongsi. Namespace mengasingkan paparan, manakala cgroups mengakaunkan dan mengehadkan penggunaan. Di sini, memory.max=536870912 boleh membawa kepada cgroup OOM selepas penuntutan semula gagal, cpu.max=50000 100000 mencekik kerja kelas saksama selepas 50 ms setiap 100 ms, dan pids.max=128 menolak fork atau clone yang melanggar dengan EAGAIN.

Saya akan menambah pemetaan UID jika sesuai, keupayaan minimum, no_new_privs, seccomp, dasar AppArmor atau SELinux, lekapan selamat, dan peranti terhad. Saya akan mengesahkan identiti namespace, peta UID, lekapan, antara muka, fail cgroup yang berkuat kuasa, keupayaan, dan keadaan keselamatan daripada kedua-dua belah pihak, kemudian menjalankan ujian terikat dan memerlukan bukti memory.events, cpu.stat, dan pids.events yang sepadan.”

Panduan Terperinci Langkah demi Langkah

Langkah 1: Mulakan dengan Model Proses Hos

Runtime menerima bundle OCI yang mengandungi sistem fail punca dan konfigurasi. Urutan persediaan yang representatif ialah:

1. sahkan bundle, fail boleh laksana, lekapan, pilihan namespace, kelayakan, dan tetapan sumber;
2. cipta atau pilih subpepohon cgroup dan tulis nilai pengawal;
3. cipta namespace baharu atau sertai namespace sedia ada yang dikonfigurasikan;
4. wujudkan pemetaan UID/GID jika user namespace digunakan;
5. jadikan perambatan lekapan selamat, lekapkan rootfs dan sistem fail khas, dan tukar punca proses;
6. cipta atau alihkan peranti rangkaian dan konfigurasikan laluan apabila namespace rangkaian baharu digunakan;
7. tetapkan kelayakan, keupayaan, no_new_privs, seccomp, dan label atau profil LSM;
8. lampirkan proses pada cgroup dan exec aplikasi yang dikonfigurasikan.

Susunan tepat dan proses pembantu berbeza-beza mengikut runtime. Perkara yang tidak berubah ialah keadaan kernel yang boleh diperhatikan: aplikasi kekal sebagai proses yang dijadualkan hos dengan keahlian namespace, kelayakan, lekapan, penapis, dan laluan cgroup. Jika runtime ranap selepas persediaan separa, pembersihan mesti mengalih keluar lekapan, antara muka, pin namespace, dan cgroups; perkataan “bekas” bukanlah objek kernel yang melakukan pembersihan secara automatik.

Langkah 2: Berikan Satu Tanggungjawab kepada Setiap Namespace

Namespace utama saling melengkapi:

Jenis namespace yang ditinggalkan daripada senarai namespace OCI diwarisi daripada runtime. --pid=host, rangkaian hos, atau menyertai namespace bekas lain boleh dilakukan secara sengaja, tetapi jawapannya mesti menyatakan pengasingan yang hilang dan bukannya masih menerangkan bekas peribadi sepenuhnya.

Sempadan sistem fail memerlukan kedua-dua namespace lekapan dan rootfs. Mod perambatan peribadi atau hamba (slave) menghalang peristiwa lekapan bekas daripada mengalir ke hos secara tidak dijangka. Lekapan baca sahaja, laluan bertopeng, /dev yang minimum, dan lekapan bind eksplisit mengecilkan akses. Lekapan bind boleh tulis bagi punca hos atau soket enjin bekas mencipta laluan langsung berimpak tinggi tanpa mengira hostname peribadi proses tersebut.

Langkah 3: Terbitkan Tiga Hasil Had Sumber

Memori. memory.max=536870912 ialah had tegar utama untuk cgroup dan keturunannya. Apabila penggunaan menghampiri had, kernel cuba melakukan penuntutan semula. Jika penggunaan mencapai had dan tidak dapat dikurangkan, cgroup memasuki pengendalian OOM; dalam mod lalai, pembunuh OOM boleh memilih tugasan dalam cgroup tersebut, dan memory.oom.group=1 boleh meminta layanan sebagai satu beban kerja yang tidak boleh dibahagikan. Bacaan ringkas di atas had boleh berlaku. Semak memory.current, memory.peak, dan medan max, oom, oom_kill, serta oom_group_kill dalam memory.events. Jangan mendiagnosis setiap SIGKILL sebagai OOM cgroup tanpa pembilang tersebut dan bukti kernel atau runtime.

CPU. cpu.max=50000 100000 bermakna tugasan kelas saksama dalam kumpulan boleh menggunakan sehingga 50,000 mikrosaat dalam setiap tempoh 100,000 mikrosaat: purata lebar jalur 0.5 CPU. Pelbagai bebenang boleh menghabiskan kuota secara serentak dan menghabiskannya lebih awal dalam tempoh tersebut. Tugasan yang boleh dijalankan kemudiannya dicekik sehingga kuota tersedia; ia tidak ditamatkan. Periksa usage_usec, nr_periods, nr_throttled, dan throttled_usec dalam cpu.stat. Oleh itu, lonjakan kependaman berhampiran sempadan tempoh boleh jadi merupakan pencekikan kuota walaupun CPU hos sebaliknya tersedia.

Tugasan. pids.max=128 ialah had tegar hierarki pada tugasan kernel. Bebenang turut dikira. Sebaik sahaja tugasan baharu melanggar dasar, fork() atau clone() gagal dengan EAGAIN; tugasan sedia ada terus berjalan. Periksa pids.current, pids.peak, dan kiraan max dalam pids.events. Mengalihkan tugasan sedia ada atau menurunkan had yang dikonfigurasikan boleh menghasilkan pids.current > pids.max secara sementara; penciptaan masih disekat daripada melanggar dasar.

Cgroup induk juga mengekang anak-anaknya. Anak tidak boleh memperoleh kapasiti CPU, memori, atau tugasan yang tidak dibenarkan oleh leluhurnya. Sebaliknya, ketiga-tiga tetapan ini tidak mengehadkan setiap sumber secara automatik: ruang storan, I/O, deskriptor fail, lebar jalur rangkaian, peranti, dan objek global kernel memerlukan kawalan dan had operasi mereka sendiri.

Langkah 4: Lapiskan Kawalan Keselamatan di Sekeliling Kernel yang Dikongsi

User namespace membolehkan proses menjadi UID 0 di dalam sambil memetakan kepada UID biasa tanpa keistimewaan di luar. Ini mengurangkan kesan pelepasan namespace atau akses fail hos yang tersilap, tetapi pemetaan dan pemilikan sistem fail mesti direka bentuk bersama. Tanpa user namespace, root dalam bekas masih merupakan UID 0 hos, walaupun keupayaan dan objek yang boleh diaksesnya dihadkan.

Keupayaan membahagikan keistimewaan root tradisional. Mulakan daripada set minimum dan bukannya memberikan semua keupayaan. Menggugurkan keupayaan hanya berguna jika proses tidak dapat memperolehnya semula melalui keupayaan fail, pelaksanaan set-user-ID, atau laluan lain; set terikat dan no_new_privs menjadikan niat itu boleh diaudit.

Seccomp menapis panggilan sistem dan boleh membenarkan, menafikan, memerangkap (trap), mematikan, mencatat log, atau memberitahu berdasarkan panggilan dan argumen. Ia mengurangkan permukaan serangan kernel yang boleh dicapai tetapi tidak memahami kebenaran peringkat aplikasi. LSM seperti AppArmor atau SELinux menggunakan dasar pada operasi pada fail, proses, soket, dan objek lain. Sistem fail baca sahaja, laluan /proc bertopeng, dan set peranti minimum menambah kekangan bebas.

Ini adalah lapisan, bukan pengganti. Cgroups terutamanya menangani perakaunan dan penafian perkhidmatan sumber; mereka tidak menghalang satu bekas daripada membaca data bekas yang lain. Namespace terutamanya mengasingkan paparan; mereka tidak menambal kernel yang dikongsi. Bagi penyewa musuh, risiko eksploitasi kernel atau pematuhan mungkin mewajarkan sempadan VM, microVM, atau kernel berkotak pasir.

Langkah 5: Sahkan Keadaan Kernel dari Kedua-dua Belah Pihak

Daripada hos, mula-mula kenal pasti proses init bekas dan laluan cgroup. Lakaran pemeriksaan generik ialah:

pid=<host-pid-of-container-init>
cg=/sys/fs/cgroup/<container-cgroup>

readlink /proc/$pid/ns/{pid,mnt,net,uts,ipc,user,cgroup}
cat /proc/$pid/uid_map
cat /proc/$pid/gid_map
cat /proc/$pid/cgroup

cat "$cg/memory.current" "$cg/memory.max" "$cg/memory.events"
cat "$cg/cpu.max" "$cg/cpu.stat"
cat "$cg/pids.current" "$cg/pids.max" "$cg/pids.events"

grep -E '^(CapPrm|CapEff|CapBnd|NoNewPrivs|Seccomp):' /proc/$pid/status

Bandingkan identiti peranti/inode pautan simbolik namespace dengan hos dan dengan bekas lain. Identiti yang berbeza membuktikan kejadian namespace yang berbeza; mereka tidak membuktikan lekapan selamat, laluan, atau dasar secara bersendirian. Periksa jadual lekapan dan perambatan sebenar, pautan dan laluan rangkaian, set keupayaan berkesan, mod seccomp, label LSM, dan nod peranti.

Di dalam bekas, rekodkan /proc/1/status, /proc/self/cgroup, mount, hostname, proses yang kelihatan, antara muka, laluan, UID/GID, dan pautan namespace. Gunakan nsenter daripada hos yang dibenarkan untuk diagnosis sahaja; memasuki namespace ialah akses istimewa, bukan bukti bahawa sempadan itu gagal.

Akhir sekali, jalankan ujian kegagalan terikat dalam persekitaran pakai buang. Peruntukkan memori secara beransur-ansur dan kaitkan kegagalan dengan memory.events; jalankan kerja CPU dan kaitkan kependaman dengan nr_throttled; cipta bebenang atau proses sehingga penciptaan seterusnya mengembalikan EAGAIN dan pids.events meningkat. Hentikan ujian sebelum tekanan peringkat hos, dan sahkan bahawa cgroup adik-beradik kekal sihat.

Langkah 6: Tukar Pemerhatian Menjadi Kriteria Penerimaan

Rekod penerimaan yang boleh dipertahankan mengandungi nilai, identiti, dan hasil:

• ID namespace berbeza di tempat pengasingan diperlukan dan hanya sepadan di tempat perkongsian disengajakan;
• pemetaan UID 0, keupayaan berkesan, NoNewPrivs, mod seccomp, dan label LSM sepadan dengan model ancaman;
• perambatan lekapan, lekapan bind, laluan bertopeng, laluan boleh tulis, dan akses peranti sepadan dengan konfigurasi OCI;
• memory.max, cpu.max, dan pids.max bersamaan dengan 536870912, 50000 100000, dan 128 pada cgroup berkesan;
• tekanan memori mengubah pembilang peristiwa memori yang berkaitan, beban CPU meningkatkan pembilang pencekikan tanpa mematikan tugasan, dan penciptaan tugasan ke-129 ditolak apabila 128 tugasan telah dicaj;
• cgroup induk dan adik-beradik kekal dalam belanjawan mereka sendiri semasa setiap ujian;
• ujian mula semula dan kegagalan paksa tidak meninggalkan lekapan, antara muka, pin namespace, atau cgroup berpenghuni yang tidak dijangka.

Penyataan tugasan ke-129 adalah bersyarat kepada tepat 128 tugasan yang telah dicaj ke hierarki berkesan dan tiada penamatan serentak. Dalam ujian sebenar, baca pids.current serta-merta sebelum penciptaan dan bukannya mengandaikan aplikasi mempunyai satu tugasan.

Contoh Jawapan yang Mantap

“Saya akan mulakan dengan model proses hos. Runtime mengambil rootfs dan konfigurasi OCI, mencipta atau menyertai namespace PID, lekapan, rangkaian, UTS, IPC, pengguna, cgroup, dan masa yang diminta, mengkonfigurasikan lekapan dan rangkaian, melampirkan pepohon proses pada cgroup, menggunakan kelayakan dan dasar keselamatan, dan melaksanakan (exec) aplikasi. PID 1 di dalam masih merupakan proses hos dengan PID lain di luar. Bekas mempunyai paparan ruang pengguna peribadi, manakala kernel hos kekal dikongsi.

Namespace dan cgroups menyelesaikan masalah yang berbeza. Namespace PID mengubah keterlihatan proses; namespace lekapan ditambah rootfs mengubah sistem fail yang kelihatan; namespace rangkaian menyediakan antara muka, laluan, port, dan soketnya sendiri. User namespace boleh memetakan UID 0 dalaman kepada UID hos tanpa keistimewaan. Cgroups mengakaunkan dan mengawal pepohon proses tetapi tidak menyembunyikan objek hos.

Untuk nilai cgroup v2 yang dinyatakan, memory.max=536870912 ialah sempadan tegar 512 MiB. Kernel mencuba penuntutan semula, kemudian boleh menggunakan pengendalian OOM cgroup jika penggunaan tidak dapat dikurangkan; Saya akan membaca memory.events untuk membezakan max, oom, dan oom_kill. cpu.max=50000 100000 membekalkan paling banyak 50 ms setiap 100 ms kepada kerja kelas saksama. Sebaik sahaja kuota digunakan, tugasan yang boleh dijalankan akan dicekik sehingga lebih banyak kuota tersedia, dan cpu.stat melaporkan nr_throttled dan throttled_usec; tiada pembunuhan had CPU. pids.max=128 mengira tugasan kernel, termasuk bebenang. Fork atau clone yang melanggar mengembalikan EAGAIN, dan pids.events merekodkan peristiwa tersebut.

Oleh kerana kernel dikongsi, saya akan melapiskan user namespace jika sesuai, set keupayaan minimum, no_new_privs, seccomp, dasar AppArmor atau SELinux, lekapan baca sahaja atau bertopeng, dan set peranti minimum. Saya akan menolak mod istimewa, namespace hos, lekapan hos yang luas, atau akses soket enjin melainkan setiap satunya adalah keperluan dipercayai yang eksplisit. Berbilang penyewa yang bermusuhan mungkin memerlukan sempadan VM atau microVM.

Untuk mengesahkan, saya akan membandingkan identiti peranti/inode /proc/{PID}/ns/*, peta UID/GID, lekapan, antara muka, laluan cgroup, fail pengawal berkesan, keupayaan, mod seccomp, dan label LSM daripada hos dan bekas. Kemudian saya akan menjalankan ujian memori, CPU, dan tugasan terikat serta memerlukan pembilang kernel dan mod kegagalan yang sepadan. Bekas yang sekadar bermula belum membuktikan pengasingan.”

Kesilapan Biasa dan Penambahbaikan

• Memanggil bekas sebagai VM kecil → ini menyembunyikan kernel yang dikongsi dan menghasilkan andaian keselamatan yang salah → terangkan proses hos dengan keadaan namespace, cgroup, sistem fail, kelayakan, dan dasar.
• Menyatakan bahawa namespace mengehadkan CPU dan memori → namespace mengasingkan paparan, bukan penggunaan → petakan had sumber kepada pengawal dan fail cgroup.
• Menyatakan bahawa cgroups mengasingkan fail dan proses → cgroups mengumpulkan, mengakaunkan, dan mengekang tugasan → petakan keterlihatan kepada namespace PID dan lekapan.
• Memperlakukan chroot sebagai bekas → mengubah punca yang kelihatan tidak menambah pengasingan PID, rangkaian, pengguna, atau sumber → gabungkan rootfs dengan lekapan dan namespace lain yang diperlukan serta dasar.
• Mendakwa had CPU mematikan proses → kuota CPU biasanya mencekik kerja kelas saksama yang boleh dijalankan → semak cpu.stat untuk pencekikan.
• Menjangkakan penggunaan memori berhenti pada tepat 512 MiB → penuntutan semula, masa perakaunan, dan lebihan sementara merumitkan bacaan segera → gunakan memory.max dan pembilang peristiwa untuk menetapkan hasil yang dikuatkuasakan.
• Hanya mengira proses terhadap pids.max → pengawal mengira tugasan kernel, jadi bebenang turut menggunakannya → periksa pids.current sebelum ujian had.
• Mengandaikan root di dalam adalah tidak berbahaya → tanpa user namespace ia mungkin masih merupakan UID 0 hos, dikekang hanya oleh kawalan lain → periksa uid_map dan keupayaan.
• Menyamakan pemisahan namespace dengan sempadan penyewa yang selamat → kerentanan kernel atau lekapan hos yang berbahaya boleh melintasi sempadan proses → nyatakan model ancaman dan tambah dasar atau sempadan VM.
• Memeriksa konfigurasi tetapi bukan keadaan berkesan → bendera runtime boleh ditindih, diwarisi, atau gagal sebahagiannya → baca /proc dan fail cgroup, kemudian laksanakan setiap had.

Soalan Susulan

Soalan Susulan 1: Mengapakah PID 1 Memerlukan Layanan Khas di Dalam Bekas?

Proses pertama dalam namespace PID boleh dilihat sebagai PID 1 oleh keturunannya. Ia mengambil anak-anak yatim (orphaned children) dan mesti menuai mereka, atau zombi akan terkumpul dan menggunakan belanjawan pids. PID 1 juga mempunyai semantik pengendalian isyarat khas, jadi pembungkus (wrapper) yang tidak memajukan isyarat boleh menyebabkan penamatan anggun gagal. Sahkan proses init sebenar, penuaian anak, pemajuan isyarat, dan tarikh akhir penutupan dan bukannya mengandaikan rangka kerja aplikasi mengendalikannya.

Soalan Susulan 2: Apakah Perbezaan Antara cpu.max dan cpu.weight?

cpu.max menetapkan lebar jalur maksimum bagi setiap tempoh untuk kerja kelas saksama. Ia boleh mencekik cgroup walaupun hos mempunyai CPU melahu selepas kumpulan itu menggunakan kuota semasanya. cpu.weight ialah keutamaan berkadar dalam kalangan cgroup adik-beradik yang boleh dijalankan semasa perbalahan dan tidak dengan sendirinya mentakrifkan siling 0.5-CPU tegar. Dasar pengeluaran boleh menggunakan kedua-duanya untuk matlamat yang berbeza.

Soalan Susulan 3: Bolehkah Root Bekas Menjadi Tidak Berkeistimewaan pada Hos?

Ya, apabila user namespace memetakan UID 0 di dalam kepada julat UID tanpa keistimewaan di luar. Sahkan pemetaan dalam /proc/{PID}/uid_map dan /proc/{PID}/gid_map. Ini mengecilkan keistimewaan hos, tetapi pemilikan lekapan bind, peruntukan ID bawahan, keupayaan dalam user namespace pemilik, dan permukaan serangan kernel masih memerlukan semakan.

Soalan Susulan 4: Mengapakah Namespace Lekapan Peribadi Tidak Mencukupi untuk Keselamatan Sistem Fail?

Ia mengasingkan jadual lekapan, tetapi runtime memutuskan sistem fail sandaran dan lekapan bind yang muncul di sana. Namespace peribadi yang mengandungi lekapan bind boleh tulis bagi / masih mendedahkan punca hos. Semak sumber lekapan, perambatan, bendera boleh tulis, laluan bertopeng dan baca sahaja, nod peranti, serta kelayakan proses dan dasar LSM secara bersama.

Soalan Susulan 5: Bilakah Anda Patut Mengutamakan VM atau MicroVM?

Utamakan sempadan yang lebih kukuh apabila penyewa yang tidak dipercayai secara bersama melaksanakan kod sewenang-wenangnya, pelepasan kernel dikongsi berada di luar risiko yang diterima, pematuhan memerlukan kernel berasingan, atau versi kernel dan modul mesti berbeza. Kosnya ialah overhed permulaan, memori, imej, dan operasi tambahan. Keputusan itu mengikut model ancaman dan kekangan platform yang diukur, bukan label bekas atau VM semata-mata.

Soalan Susulan 6: Bagaimanakah Anda Mendiagnosis Bekas yang Perlahan tetapi Tidak Dimatikan oleh OOM?

Kaitkan kependaman aplikasi dengan pencekikan cpu.stat, tekanan tinggi/maksimum memory.events, maklumat pegun tekanan (pressure-stall information), statistik pengawal I/O, penjadualan hos, dan ralat rangkaian. Peningkatan nr_throttled atau throttled_usec dengan pembilang OOM yang stabil menunjukkan ke arah kuota CPU. Tekanan penuntutan semula atau I/O juga boleh menghentikan kerja tanpa pembunuhan, jadi diagnosis memerlukan cap masa yang sejajar dan salasilah cgroup yang berkesan.