Tanya Jawab Umum untuk pembuangan data

Artikel ini menjawab pertanyaan umum tentang mengumpulkan cadangan di .NET.

Mengapa pengumpulan dumping gagal di Linux?

Untuk menerapkan pengumpulan dump, proses .NET memunculkan proses anak yang disebut createdump. Proses anak ini menggunakan Linux API ptrace() dan juga membaca dari sistem file /proc untuk mengakses thread dan data memori yang ditulis ke dalam file dump. Meskipun penggunaan API diizinkan oleh pengaturan keamanan default pada banyak distro Linux, terkadang konfigurasi keamanan yang kurang umum akan menolak akses. Anda mungkin melihat output dari proses createdump yang ditulis di konsol aplikasi yang sedang di-dump, seperti:

[createdump] The process or container does not have permissions or access: open(/proc/1234/mem) FAILED Permission denied (13)

Salah satu alasan akses dapat ditolak adalah jika sandbox keamanan mencegat panggilan menggunakan filter BPF seccomp. Untuk aplikasi yang berjalan dalam kontainer menggunakan teknologi Open Container Initiative, seccomp profil harus memungkinkan panggilan ke ptrace. Misalnya, Docker menggunakan containerd secara internal sebagai runtime kontainer. Saat menginisialisasi, ini menentukan profil seccomp default yang hanya memungkinkan ptrace jika host kontainer memiliki versi kernel yang lebih tinggi dari 4.8 atau jika CAP_SYS_PTRACE kemampuan ditentukan pada kontainer.

Jika panggilan tidak dicegat, maka kernel melakukan berbagai pemeriksaan akses bawaan. Dokumen untuk ptrace() mencakup deskripsi terperinci di dekat akhir, berjudul "Pemeriksaan mode akses Ptrace", yang menjelaskan bagaimana hal ini dilakukan. Mengakses sistem file /proc juga menggunakan variasi pemeriksaan mode akses ptrace yang sama. Berikut ini adalah ringkasan singkat dari pemeriksaan keamanan yang dilakukan dan tempat di mana akses mungkin ditolak:

• Baik proses panggilan harus memiliki ID pengguna yang sama dengan proses target, atau proses panggilan harus memiliki CAP_SYS_PTRACE. Jika kedua kondisi tersebut tidak benar, akses ditolak. Karena runtime .NET tidak melakukan apa pun untuk mengubah akun pengguna saat meluncurkan createdump, ID pengguna harus cocok dan langkah ini harus berhasil.
• Jika createdump tidak memiliki CAP_SYS_PTRACE (secara default, tidak memiliki), maka proses target yang di-dump perlu ditandai "dapat di-dump". Secara default, sebagian besar proses di Linux dapat diduplikasi, tetapi Anda dapat mengubah pengaturan ini dengan memanggil prctl() dengan opsi PR_SET_DUMPABLE. Jika Anda menambahkan kemampuan ke proses menggunakan alat setcap, ini juga dapat menyebabkan proses berhenti dapat di-dump. Untuk penjelasan lebih rinci tentang pengaturan dumpable dan apa penyebab pengaturannya dinonaktifkan, lihat dokumentasi Linux.
• Semua modul keamanan Linux (LSM) yang diaktifkan dijumlahkan dan masing-masing harus menyetujui akses. Sayangnya, jika LSM menolak akses, tidak ada mekanisme pelaporan Linux yang seragam untuk mengetahui mana yang bertanggung jawab. Sebagai gantinya, Anda perlu menentukan mana yang diaktifkan pada sistem Anda dan kemudian menyelidiki masing-masing secara individual. Anda dapat menentukan LSM mana yang aktif dengan menjalankan: cat /sys/kernel/security/lsm. Meskipun setiap LSM dapat bertanggung jawab, Yama, SELinux, dan AppArmor sering menjadi yang relevan.

AppArmor dan SELinux keduanya memiliki konfigurasi yang kaya dan mekanisme pelaporan, jadi jika Anda perlu mempelajari cara bekerja dengan mereka, yang terbaik adalah melihat dokumentasi setiap proyek sendiri. Yama hanya memiliki satu pengaturan konfigurasi, yang dapat ditampilkan dengan menjalankan:

cat /proc/sys/kernel/yama/ptrace_scope

Perintah ini menghasilkan angka yang menunjukkan kebijakan keamanan ptrace Yama saat ini:

• 0: Izin ptrace klasik.
• 1: Ptrace terbatas.
• 2: Hanya admin yang dapat melampirkan.
• Tidak ada lampiran.

Yama harus mengizinkan akses untuk createdump sesuai dengan kebijakan 0 dan 1, tetapi diharapkan akses akan ditolak sesuai dengan kebijakan 2 dan 3. Kebijakan 3 selalu menolak akses, dan kebijakan 2 tidak berfungsi secara default karena createdump biasanya tidak memiliki kemampuan CAP_SYS_PTRACE.

Mengapa saya hanya mendapatkan cadangan di Linux jika dotnet-dump atau proses crash saya berjalan ditingkatkan?

Beberapa sistem berbasis Linux dikonfigurasi dengan kebijakan keamanan yang memerlukan setiap proses yang mengumpulkan dump data agar memiliki kapabilitas bernama CAP_SYS_PTRACE. Biasanya proses tidak memiliki kemampuan ini, tetapi menjalankan dengan hak akses tinggi adalah salah satu cara untuk mengaktifkannya. Untuk deskripsi yang lebih lengkap tentang bagaimana kebijakan keamanan Linux memengaruhi pengumpulan cadangan, lihat 'Mengapa pengumpulan cadangan gagal di Linux?'.

Mengapa saya tidak dapat mengumpulkan cadangan saat berjalan di dalam kontainer?

Untuk aplikasi yang berjalan di bawah teknologi Open Container Initiative, seccomp profil harus memungkinkan panggilan ke ptrace(). Misalnya, Docker menggunakan containerd sebagai komponen internal untuk runtime kontainer. Saat menginisialisasi runtime, profil seccomp default ditentukan yang memungkinkan ptrace hanya jika host kontainer memiliki versi kernel yang lebih tinggi dari 4.8 atau jika CAP_SYS_PTRACE kemampuan tersebut telah ditentukan.

Untuk deskripsi yang lebih lengkap tentang bagaimana kebijakan keamanan Linux memengaruhi pengumpulan cadangan, lihat pertanyaan 'Mengapa pengumpulan cadangan gagal di Linux?'.

Mengapa saya tidak dapat mengumpulkan cadangan di macOS?

Di macOS, penggunaan ptrace mengharuskan host proses target untuk berhak dengan benar. Untuk informasi tentang hak minimum yang diperlukan, lihat Hak default.

Mengapa saya tidak dapat mengumpulkan dump di Android atau iOS?

Pengumpulan dump tidak didukung pada platform seluler (Android dan iOS). Platform ini menggunakan runtime Mono, yang tidak mendukung pembuatan cadangan memori.

Di mana saya dapat mempelajari selengkapnya tentang bagaimana saya dapat memanfaatkan cadangan untuk membantu mendiagnosis masalah di aplikasi .NET saya?

Berikut adalah beberapa sumber daya tambahan:

• Debug dump Linux
• Debug deadlock pada aplikasi .NET

Bagaimana cara memecahkan "Tidak mungkin menemukan versi kerangka kerja yang kompatibel"

Di Linux, DOTNET_ROOT variabel lingkungan harus menunjuk ke folder yang benar saat diatur. Ketika menunjuk ke versi .NET lain, dotnet-dump selalu menghasilkan kesalahan ini. DOTNET_ROOT Ketika variabel lingkungan tidak diatur, kesalahan yang berbeda dihasilkan ("Anda harus menginstal .NET untuk menjalankan aplikasi ini").

Artikel ini menjawab pertanyaan umum tentang mengumpulkan cadangan di .NET.

Untuk menerapkan pengumpulan dump, proses .NET memunculkan proses anak yang disebut createdump. Proses anak ini menggunakan Linux API ptrace() dan juga membaca dari sistem file /proc untuk mengakses thread dan data memori yang ditulis ke dalam file dump. Meskipun penggunaan API diizinkan oleh pengaturan keamanan default pada banyak distro Linux, terkadang konfigurasi keamanan yang kurang umum akan menolak akses. Anda mungkin melihat output dari proses createdump yang ditulis di konsol aplikasi yang sedang di-dump, seperti:

[createdump] The process or container does not have permissions or access: open(/proc/1234/mem) FAILED Permission denied (13)

Salah satu alasan akses dapat ditolak adalah jika sandbox keamanan mencegat panggilan menggunakan filter BPF seccomp. Untuk aplikasi yang berjalan dalam kontainer menggunakan teknologi Open Container Initiative, seccomp profil harus memungkinkan panggilan ke ptrace. Misalnya, Docker menggunakan containerd secara internal sebagai runtime kontainer. Saat menginisialisasi, ini menentukan profil seccomp default yang hanya memungkinkan ptrace jika host kontainer memiliki versi kernel yang lebih tinggi dari 4.8 atau jika CAP_SYS_PTRACE kemampuan ditentukan pada kontainer.

Jika panggilan tidak dicegat, maka kernel melakukan berbagai pemeriksaan akses bawaan. Dokumen untuk ptrace() mencakup deskripsi terperinci di dekat akhir, berjudul "Pemeriksaan mode akses Ptrace", yang menjelaskan bagaimana hal ini dilakukan. Mengakses sistem file /proc juga menggunakan variasi pemeriksaan mode akses ptrace yang sama. Berikut ini adalah ringkasan singkat dari pemeriksaan keamanan yang dilakukan dan tempat di mana akses mungkin ditolak:

• Baik proses panggilan harus memiliki ID pengguna yang sama dengan proses target, atau proses panggilan harus memiliki CAP_SYS_PTRACE. Jika kedua kondisi tersebut tidak benar, akses ditolak. Karena runtime .NET tidak melakukan apa pun untuk mengubah akun pengguna saat meluncurkan createdump, ID pengguna harus cocok dan langkah ini harus berhasil.
• Jika createdump tidak memiliki CAP_SYS_PTRACE (secara default, tidak memiliki), maka proses target yang di-dump perlu ditandai "dapat di-dump". Secara default, sebagian besar proses di Linux dapat diduplikasi, tetapi Anda dapat mengubah pengaturan ini dengan memanggil prctl() dengan opsi PR_SET_DUMPABLE. Jika Anda menambahkan kemampuan ke proses menggunakan alat setcap, ini juga dapat menyebabkan proses berhenti dapat di-dump. Untuk penjelasan lebih rinci tentang pengaturan dumpable dan apa penyebab pengaturannya dinonaktifkan, lihat dokumentasi Linux.
• Semua modul keamanan Linux (LSM) yang diaktifkan dijumlahkan dan masing-masing harus menyetujui akses. Sayangnya, jika LSM menolak akses, tidak ada mekanisme pelaporan Linux yang seragam untuk mengetahui mana yang bertanggung jawab. Sebagai gantinya, Anda perlu menentukan mana yang diaktifkan pada sistem Anda dan kemudian menyelidiki masing-masing secara individual. Anda dapat menentukan LSM mana yang aktif dengan menjalankan: cat /sys/kernel/security/lsm. Meskipun setiap LSM dapat bertanggung jawab, Yama, SELinux, dan AppArmor sering menjadi yang relevan.

AppArmor dan SELinux keduanya memiliki konfigurasi yang kaya dan mekanisme pelaporan, jadi jika Anda perlu mempelajari cara bekerja dengan mereka, yang terbaik adalah melihat dokumentasi setiap proyek sendiri. Yama hanya memiliki satu pengaturan konfigurasi, yang dapat ditampilkan dengan menjalankan:

cat /proc/sys/kernel/yama/ptrace_scope

Perintah ini menghasilkan angka yang menunjukkan kebijakan keamanan ptrace Yama saat ini:

• 0: Izin ptrace klasik.
• 1: Ptrace terbatas.
• 2: Hanya admin yang dapat melampirkan.
• Tidak ada lampiran.

Yama harus mengizinkan akses untuk createdump sesuai dengan kebijakan 0 dan 1, tetapi diharapkan akses akan ditolak sesuai dengan kebijakan 2 dan 3. Kebijakan 3 selalu menolak akses, dan kebijakan 2 tidak berfungsi secara default karena createdump biasanya tidak memiliki kemampuan CAP_SYS_PTRACE.

Beberapa sistem berbasis Linux dikonfigurasi dengan kebijakan keamanan yang memerlukan setiap proses yang mengumpulkan dump data agar memiliki kapabilitas bernama CAP_SYS_PTRACE. Biasanya proses tidak memiliki kemampuan ini, tetapi menjalankan dengan hak akses tinggi adalah salah satu cara untuk mengaktifkannya. Untuk deskripsi yang lebih lengkap tentang bagaimana kebijakan keamanan Linux memengaruhi pengumpulan cadangan, lihat 'Mengapa pengumpulan cadangan gagal di Linux?'.

Untuk aplikasi yang berjalan di bawah teknologi Open Container Initiative, seccomp profil harus memungkinkan panggilan ke ptrace(). Misalnya, Docker menggunakan containerd sebagai komponen internal untuk runtime kontainer. Saat menginisialisasi runtime, profil seccomp default ditentukan yang memungkinkan ptrace hanya jika host kontainer memiliki versi kernel yang lebih tinggi dari 4.8 atau jika CAP_SYS_PTRACE kemampuan tersebut telah ditentukan.

Untuk deskripsi yang lebih lengkap tentang bagaimana kebijakan keamanan Linux memengaruhi pengumpulan cadangan, lihat pertanyaan 'Mengapa pengumpulan cadangan gagal di Linux?'.

Di macOS, penggunaan ptrace mengharuskan host proses target untuk berhak dengan benar. Untuk informasi tentang hak minimum yang diperlukan, lihat Hak default.

Pengumpulan dump tidak didukung pada platform seluler (Android dan iOS). Platform ini menggunakan runtime Mono, yang tidak mendukung pembuatan cadangan memori.

Berikut adalah beberapa sumber daya tambahan:

• Debug dump Linux
• Debug deadlock pada aplikasi .NET

Di Linux, DOTNET_ROOT variabel lingkungan harus menunjuk ke folder yang benar saat diatur. Ketika menunjuk ke versi .NET lain, dotnet-dump selalu menghasilkan kesalahan ini. DOTNET_ROOT Ketika variabel lingkungan tidak diatur, kesalahan yang berbeda dihasilkan ("Anda harus menginstal .NET untuk menjalankan aplikasi ini").