Inode yang sama dapat terlihat memiliki ownership berbeda melalui dua mount point tanpa chown() rekursif. Idmapped mount Linux menempelkan ID mapping pada sebuah mount, sehingga penyajian ownership dan pemeriksaan permission di VFS dapat menerjemahkan user ID serta group ID untuk view tersebut sementara ownership yang disimpan filesystem tetap sama.

Properti ini memisahkan metadata inode persisten dari view identitas yang diekspos pada mount tertentu. Mekanisme tersebut berguna ketika satu pohon filesystem perlu dipakai container dengan user namespace yang memetakan ID secara berbeda dari host.

Mapping melekat pada mount

Idmapped mount membawa ID mapping yang berasal dari user namespace. mount_setattr() menerapkannya melalui MOUNT_ATTR_IDMAP, sedangkan userns_fd menunjuk namespace yang menyediakan mapping.

Mapping tidak ditulis ke setiap inode. Mount kedua dari filesystem yang sama dapat tetap memakai identity mapping biasa dan terus menampilkan ownership asli. Remapping hanya berlaku pada idmapped mount dan mengikuti lifetime mount tersebut.

Perilaku ini berbeda secara mendasar dari:

chown -R 100000:100000 tree/

Perubahan ownership rekursif memodifikasi metadata filesystem, menyentuh setiap inode yang terlibat, dan mengubah hasil yang dilihat semua mount. Idmapped mount hanya mengubah interpretasi ownership pada boundary VFS.

Ownership melintasi beberapa domain ID

Pemeriksaan permission filesystem tidak dapat menganggap UID numerik memiliki arti global. Caller memiliki ID yang ditafsirkan melalui user namespace, inode memiliki ownership dalam domain ID filesystem, dan idmapped mount dapat menambahkan translasi di antara keduanya.

Secara konseptual, lookup path melalui idmapped mount memiliki hubungan seperti:

identitas caller
      |
user namespace caller
      |
ID mapping mount
      |
domain ownership filesystem
      |
uid/gid inode

Helper VFS kernel melakukan translasi yang diperlukan ketika ownership dilaporkan atau keputusan permission dibuat. Representasi internal tepatnya merupakan detail implementasi; properti arsitekturalnya adalah logika permission menerima mapping mount dan tidak menganggap ID mentah inode sudah berada pada domain identitas caller.

ID di luar mapping yang dikonfigurasi tidak dapat diterjemahkan secara normal. Celah mapping karena itu penting ketika hanya rentang tertentu yang dipetakan.

Pemeriksaan permission memakai ownership hasil translasi

Fitur ini bukan sekadar perubahan kosmetik pada output stat(). Operasi VFS yang mendukung idmapped mount memakai mapping mount dalam pemeriksaan yang sensitif terhadap ownership dan perubahan metadata.

Misalnya, file pada disk dapat dimiliki host ID yang bersesuaian dengan UID 0 di dalam user namespace container. Mengekspos pohon tersebut melalui idmapped mount yang sesuai dapat membuat file terlihat dimiliki identitas container dan membuat pemeriksaan berbasis ownership bekerja dengan relasi hasil translasi itu. Mount host biasa tetap dapat menampilkan ownership host asli.

Hal ini menghindari konflik umum pada storage container: menggeser ownership di disk untuk satu container dapat menyulitkan host atau container lain yang memakai mapping berbeda. Translasi per-mount memungkinkan beberapa view hidup berdampingan tanpa berulang kali menulis ulang pohon file.

Idmapping tidak melewati mode bit, policy ACL, keputusan LSM, mount flag, atau lapisan kontrol akses lain. Mekanisme ini mengubah nilai identitas pada jalur VFS yang memang menerapkan mapping mount.

Metadata lain yang membawa ID juga memerlukan semantik mapping

Field UID dan GID bukan satu-satunya metadata filesystem yang dapat membawa identitas. Entri POSIX ACL dapat menyimpan user ID atau group ID, dan format file capability tertentu membawa root user ID.

Dukungan idmapped mount karena itu melampaui nilai owner dan group inode yang dicetak tooling. Jalur VFS yang mendukung fitur ini menerjemahkan metadata pembawa identitas yang relevan agar maknanya konsisten dengan view ownership mount.

Hal ini juga menetapkan boundary bagi implementasi filesystem. Filesystem harus mendukung idmapped mount dengan benar; user space tidak dapat menganggap mapping arbitrer valid untuk setiap filesystem. mount_setattr() dapat menolak MOUNT_ATTR_IDMAP ketika filesystem di bawahnya tidak menyediakan dukungan tersebut.

Pembuatan mapping memiliki constraint eksplisit

Jalur klasik mount_setattr() tidak mengizinkan mount yang sudah terlihat diubah secara arbitrer menjadi view identitas baru. Mount untuk operasi ini merupakan detached mount yang dibuat dari clone mount tree, umumnya melalui open_tree() dengan OPEN_TREE_CLONE.

Caller juga memerlukan capability administratif yang disyaratkan pada user namespace terkait mount filesystem, filesystem harus mendukung idmapped mount, dan mount harus memenuhi constraint state serta writer yang ditetapkan kernel.

Control flow tipikalnya berbentuk:

mount yang ada
     |
open_tree(..., OPEN_TREE_CLONE)
     |
detached mount fd
     |
mount_setattr(..., MOUNT_ATTR_IDMAP, userns_fd)
     |
move_mount(...)
     |
idmapped view menjadi terlihat

Urutan tersebut menjadikan transformasi identitas sebagai bagian dari konstruksi mount view, bukan mutasi metadata tanpa batas pada hierarchy yang sedang aktif.

Mapping sebuah idmapped mount juga bukan policy knob mutable yang dapat diganti begitu saja. Aplikasi sebaiknya memperlakukan mapping terpilih sebagai bagian dari identitas mount object dan membangun mount view baru ketika mapping berbeda diperlukan.

Container menghindari pergeseran ownership rekursif

Container rootless dan user-namespaced sering memakai mapping non-identitas. Container UID 0, misalnya, dapat bersesuaian dengan rentang UID host yang bukan nol. Tanpa remapping pada level mount, storage tree yang disiapkan untuk satu rentang ID dapat membutuhkan perubahan ownership rekursif sebelum domain identitas lain dapat memakainya secara natural.

chown() rekursif memiliki biaya di luar waktu eksekusi. Operasi tersebut memodifikasi metadata persisten, dapat menghasilkan write amplification besar pada tree dengan banyak inode, mengubah ownership yang terlihat bagi pengguna filesystem lain, dan mempersulit pembagian data yang sama antara beberapa mapping.

Idmapped mount mempertahankan ownership persisten dan memindahkan translasi ke waktu akses. Lifetime view ownership alternatif menjadi eksplisit: ketika mount dilepas, view alternatif hilang tanpa rewrite ownership balik.

Mekanisme ini tidak otomatis membuat mapping container yang tidak berkaitan menjadi kompatibel. Rentang yang dikonfigurasi tetap harus memetakan identitas yang dibutuhkan workload, sedangkan permission di luar rentang tersebut tetap mengikuti aturan mapping dan akses normal.

Security boundary tetap berada pada jalur akses filesystem

Idmapped mount mengubah interpretasi identitas; mekanisme ini tidak memberikan authority yang tidak berkaitan dengan mapping tersebut. Container tidak dapat memakai idmapped view sebagai jalur generik menuju privilege host. Namespace capability, pemeriksaan permission VFS, policy LSM, restriction filesystem, dan topologi mount tetap berperan dalam keputusan akses.

Perbedaan ini penting saat mengevaluasi deployment. Pernyataan bahwa file terlihat dimiliki root di dalam container menjelaskan view hasil translasi, bukan klaim bahwa inode berubah menjadi milik root host atau bahwa root container memperoleh authority root host.

Properti yang bertahan lebih sempit dan lebih berguna: sebuah mount dapat menyajikan ownership filesystem melalui ID mapping terpilih, dan operasi VFS yang mendukung mekanisme tersebut menerapkan mapping itu secara konsisten pada perilaku yang sensitif terhadap ownership. Sistem container dan storage memperoleh boundary identitas lokal tanpa mengubah adaptasi ownership menjadi rewrite inode secara massal.

Rekayasa Perangkat Lunak Linux Filesystem Container