Sebuah proses memanggil execve() untuk binary pada filesystem yang dipantau, tetapi kernel tidak langsung menyelesaikan execution open. Sebuah grup fanotify meminta FAN_OPEN_EXEC_PERM, sehingga akses menunggu ketika listener userspace menerima event lalu mengembalikan FAN_ALLOW atau FAN_DENY. Mekanisme ini menyisipkan keputusan userspace sinkron ke dalam operasi filesystem yang semestinya berjalan setelah pemeriksaan permission kernel biasa.
Titik intersepsi tersebut berguna bagi policy engine yang memerlukan informasi di luar permission inode biasa, tetapi juga membentuk batas enforcement tersendiri. Availability kini bergantung pada responder userspace, cakupan event bergantung pada mark dan kelas event fanotify yang dipilih, dan mekanisme ini tidak mengubah setiap bentuk penggunaan file menjadi operasi yang dimediasi.
Event permission adalah gerbang sinkron
Fanotify memisahkan notification event dari permission event. Notifikasi seperti FAN_OPEN melaporkan aktivitas tanpa meminta listener mengotorisasinya. Permission event justru menahan operasi pemicu sampai listener menulis struct fanotify_response yang memuat file descriptor event dan nilai respons.
Tiga tipe permission event yang mapan mencakup titik akses berbeda. FAN_OPEN_PERM memediasi permintaan open, FAN_ACCESS_PERM memediasi akses read, dan FAN_OPEN_EXEC_PERM memediasi open dengan intent eksekusi. Event ini memerlukan grup fanotify yang dibuat dengan FAN_CLASS_PRE_CONTENT atau FAN_CLASS_CONTENT; FAN_CLASS_NOTIF tidak dapat memberikan keputusan akses.
Perbedaan itu penting karena nama event menentukan gerbangnya. Policy yang khusus memeriksa eksekusi program langsung dapat memakai FAN_OPEN_EXEC_PERM tanpa memperlakukan setiap open file data biasa sebagai keputusan eksekusi. Sebaliknya, keputusan FAN_OPEN_PERM terjadi saat open dan bukan lease otorisasi berkelanjutan untuk setiap operasi berikutnya yang mungkin dilakukan aplikasi melalui interface kernel lain.
Event membawa objek, bukan sekadar pathname
Dalam format event tradisional, fanotify dapat memberikan file descriptor yang merujuk ke objek terkait event. Listener dapat memeriksa objek tersebut saat task pemicu menunggu. Open file description untuk descriptor event ini memiliki flag internal FMODE_NONOTIFY, yang menekan event fanotify rekursif ketika listener mengakses objek yang dilaporkan melalui descriptor tersebut.
Serah terima berbasis objek ini mencegah pathname hasil rekonstruksi menjadi satu-satunya identitas bagi sebuah keputusan. Pathname dapat berubah akibat operasi rename dan objek dasar yang sama dapat tersedia melalui beberapa rute namespace. Mode pelaporan fanotify yang lebih baru juga dapat menyertakan record informasi file handle dan proses, sesuai flag inisialisasi yang dipilih serta dukungan kernel.
Metadata event secara default juga melaporkan PID proses pemicu, atau thread ID ketika FAN_REPORT_TID diminta. Identifier tersebut berguna sebagai konteks, tetapi tidak semestinya dianggap sebagai identitas proses yang tahan lama setelah siklus hidup event selesai. Identifier proses numerik dapat digunakan kembali setelah sebuah task berakhir; policy yang melakukan tindak lanjut asinkron memerlukan strategi terpisah untuk referensi proses yang stabil.
Mediasi eksekusi memiliki pemicu yang lebih sempit daripada eksekusi script
FAN_OPEN_EXEC_PERM terkait dengan file yang dibuka dengan intent eksekusi oleh interface eksekusi langsung seperti execve() dan execveat(). Event ini tidak otomatis mengidentifikasi sebuah script hanya karena interpreter kemudian membaca script tersebut sebagai data. Saat script diberikan kepada interpreter, executable open milik interpreter dan pembacaan script berikutnya merupakan operasi berbeda.
Batas ini mencegah policy execution-open digambarkan sebagai mediasi universal atas konten kode. Deployment yang perlu memeriksa input interpreter harus memperhitungkan jalur read atau open yang relevan selain executable open langsung. Dynamic linker dan objek executable lain juga dapat menghasilkan event execution-open ketika objek tersebut dibuka dalam mode itu.
Karena itu, policy bergantung pada model eksplisit mengenai operasi kernel mana yang mewakili transisi sensitif terhadap keamanan. Mencocokkan suffix nama file atau menganggap setiap program yang dieksekusi selalu memetakan ke satu event FAN_OPEN_EXEC_PERM bukan model yang memadai.
Cakupan mark menentukan permukaan enforcement
Mark fanotify dapat menargetkan objek filesystem individual, mount, atau instance filesystem, bergantung pada tipe mark dan fitur event yang diminta. Mount mark mencakup akses yang dilakukan melalui mount tersebut. Objek filesystem dasar yang sama dapat dijangkau melalui mount lain, dan event yang melewati rute lain itu tidak otomatis tercakup oleh mark pada mount pertama.
Filesystem mark memberikan cakupan yang lebih luas pada berbagai mount dari satu instance filesystem. Directory mark memiliki semantik child-event yang berbeda dan bukan primitive umum untuk pohon direktori rekursif. Pemilihan cakupan mark dengan demikian merupakan bagian dari batas keamanan, bukan detail operasional.
Hal ini juga membedakan fanotify dari allowlist pathname. Kernel menghasilkan event sesuai mark yang terkait dengan objek dan cakupan filesystem. Userspace dapat memperoleh nama untuk policy atau logging, tetapi cakupan enforcement berasal dari mark dan event mask tersebut.
Responder menjadi bagian dari availability
Permission event tetap pending setelah userspace membacanya sampai sebuah keputusan ditulis. Inspeksi yang lambat karena itu langsung menambah latensi pada operasi file yang tertahan. Listener yang macet dapat menahan operasi, sehingga penanganan queue, batas kerja inspeksi, dan perilaku saat gagal menjadi bagian dari desain availability layanan.
Menutup descriptor terakhir untuk sebuah grup fanotify melepaskan grup tersebut. Permission event yang masih outstanding diizinkan ketika grup ditutup. Perilaku ini berarti terminasi listener tidak sama dengan kondisi deny permanen. Deployment yang memerlukan semantik fail-closed saat daemon gagal membutuhkan supervision dan policy sistem di sekitarnya, bukan menganggap grup fanotify sendiri menyediakan jaminan tersebut.
Kapasitas queue merupakan batas lain. Fanotify dapat melaporkan FAN_Q_OVERFLOW ketika event queue melampaui limit. Hilangnya notification event terutama merusak observasi, sedangkan desain yang bergantung pada riwayat event lengkap untuk state policy berikutnya dapat mengalami masalah konsistensi yang lebih dalam. Resource limit dan penanganan overflow perlu sesuai dengan arsitektur policy.
Fanotify tidak mengamati setiap jalur menuju konten file
Fanotify melaporkan event yang dipicu userspace melalui jalur filesystem API yang didukung. Limitasi terdokumentasinya mencakup akses atau modifikasi file yang timbul dari mmap(), msync(), dan munmap() yang tidak dilaporkan sebagai event akses atau modifikasi fanotify biasa. Aktivitas remote pada network filesystem juga berada di luar model ketika tidak berasal dari filesystem API userspace lokal.
Pengecualian ini penting ketika fanotify digunakan sebagai komponen enforcement, bukan sekadar audit feed. Sebuah permission gate dapat presisi untuk operasi yang diintersepsi sambil tetap membiarkan jalur data lain di luar model event-nya. Discretionary access control kernel, mandatory access control, mount policy, mekanisme integritas file, dan isolasi aplikasi tetap merupakan kontrol terpisah dengan cakupan berbeda.
Permission event fanotify karena itu paling tepat diperlakukan sebagai policy hook sinkron dengan pemicu yang dibatasi secara eksplisit. Nilai keamanannya berasal dari penempatan operasi filesystem tertentu di balik keputusan userspace; batasannya juga konkret: batas yang dihasilkan hanya seluas tipe event, cakupan mark, perilaku kernel, dan siklus hidup responder yang mendefinisikannya.