Wawancara Linux: Hard Link vs Symbolic Link

Prompt dan Konteks yang Berlaku

Sebuah layanan men-deploy /srv/releases/v1/app.conf. Layanan ini membuat /srv/live/pinned.conf sebagai hard link dan /srv/live/current.conf sebagai relative symbolic link. Sebuah worker membuka file rilis tersebut sebelum seorang operator mengubah nama dan kemudian menghapus entri direktori.

Jelaskan apa yang dirujuk oleh sebuah nama file, hard link, symbolic link, inode, dan open file descriptor. Prediksikan hasilnya setelah setiap operasi. Kemudian pilih mekanisme yang tepat untuk snapshot yang immutable, pointer rilis yang dapat dipindahkan, dan referensi lintas-filesystem. Jawaban ini ditujukan untuk sistem Linux dan file biasa; snapshot spesifik-filesystem dan shortcut Windows berada di luar cakupan.

Apa yang Dievaluasi oleh Pewawancara

Sinyal pertama adalah model objek. Sebuah entri direktori mengikat satu nama ke sebuah inode. Sebuah hard link adalah entri direktori lain untuk inode yang sama; tidak ada nama yang berstatus sebagai "nama asli". Sebuah symbolic link adalah objek filesystem berbeda yang payload-nya berupa pathname yang di-resolve saat digunakan.

Sinyal kedua adalah penalaran siklus hidup (lifecycle reasoning). unlink menghapus satu entri direktori, belum tentu objek filenya. Inode dan data tetap ada selama hard link lain atau open file description masih mereferensikannya. Sebuah symbolic link dapat tetap ada meskipun path yang disimpannya tidak lagi dapat di-resolve.

Sinyal ketiga adalah memprediksi operasi, bukan sekadar menghafal tabel perbandingan. Mengubah nama satu hard link tidak mengubah peer-nya. Mengubah nama symlink beroperasi pada symlink itu sendiri. Memindahkan symlink atau targetnya dapat mengubah arti dari sebuah relative path. Hard link lintas-filesystem gagal karena identitas inode bersifat lokal untuk satu filesystem.

Sinyal terakhir adalah penilaian operasional: memeriksa identitas dan count link, membedakan stat dari lstat, melakukan penggantian atomik pada filesystem yang sama jika diperlukan, dan menghindari race condition check-then-open pada path yang dikendalikan penyerang.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Apakah sumber dan nama hard-link baru berada di filesystem ter-mount yang sama? Jika tidak, link gagal dengan EXDEV; menyalin data atau menggunakan symlink menyelesaikan masalah yang berbeda.
• Apakah pemanggil membutuhkan objek yang stabil atau nama yang dapat dipindahkan? Hard link mematok satu inode. Alias rilis biasanya berupa symlink yang entri direktorinya dapat diganti.
• Apakah target berupa file reguler atau direktori? Linux biasanya melarang hard link ke direktori, sedangkan symlink dapat menamai keduanya.
• Apakah symlink bersifat absolut atau relatif? Target relatif di-resolve dari direktori yang memuat symlink tersebut, bukan dari direktori kerja proses saat ini (current working directory).
• Apakah ada proses yang sudah membuka file tersebut? Mengubah nama atau meng-unlink suatu pathname tidak mengalihkan descriptor yang ada; proses tersebut tetap menggunakan objek yang sudah dibuka.
• Haruskah pengalihan bersifat atomik bagi pembaca? Penggantian dengan rename bersifat atomik hanya di dalam filesystem ter-mount yang sama. Pemindahan lintas-filesystem memerlukan protokol publikasi yang berbeda.
• Apakah komponen path dikendalikan oleh pengguna yang tidak tepercaya? Jika ya, lstat sebelumnya yang diikuti oleh open rentan terhadap race condition. Operasi open itu sendiri yang harus menegakkan kebijakan traversal.

Kerangka Jawaban 30 Detik

“Hard link adalah entri direktori kedua ke inode yang sama, sehingga kedua nama berbagi data dan metadata. Symlink memiliki inode-nya sendiri dan menyimpan sebuah path, yang di-resolve saat diakses. Menghapus satu nama hard link mengurangi link count; objek tetap bertahan melalui hard link lain dan descriptor yang terbuka. Menghapus atau mengubah nama target dapat menyebabkan symlink menjadi dangling.

Saya akan memverifikasinya dengan ls -li, stat, lstat atau readlink, dan sebuah descriptor yang sudah terbuka. Saya akan menggunakan hard link untuk mematok file persis di dalam satu filesystem, symlink untuk alias rilis yang dapat diganti atau referensi lintas-filesystem, dan symlink sementara ditambah rename pada filesystem yang sama untuk pengalihan alias secara atomik. Path yang tidak tepercaya memerlukan kebijakan open atomik tanpa-symlink atau beneath-directory, bukan pemeriksaan terpisah.”

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Bangun model nama-ke-objek

Untuk file biasa, direktori menyimpan nama dan referensi inode. Inode memuat tipe file, kepemilikan, mode, timestamp, ukuran, pemetaan blok, dan hard-link count. Konten file bukan milik satu “nama file asli” yang istimewa.

Sebuah hard link menambahkan entri direktori lain ke inode tersebut. Mengubah byte atau mode melalui salah satu nama akan terlihat melalui nama lainnya. Sebaliknya, symlink memiliki inode-nya sendiri dan menyimpan string seperti ../releases/v1/app.conf; pencarian pathname normal mengikuti string tersebut ke nama lain.

Langkah 2: Jalankan eksperimen konkret

Perintah-perintah berikut membentuk skenario ini. File descriptor shell sengaja dibiarkan terbuka:

mkdir -p /srv/releases/v1 /srv/live
printf 'version=1\n' > /srv/releases/v1/app.conf
ln /srv/releases/v1/app.conf /srv/live/pinned.conf
ln -s ../releases/v1/app.conf /srv/live/current.conf
exec 3< /srv/releases/v1/app.conf

ls -li /srv/releases/v1/app.conf /srv/live/pinned.conf
readlink /srv/live/current.conf
stat -L -c '%F %i %h' /srv/live/current.conf
stat -c '%F %i %h' /srv/live/current.conf

mv /srv/releases/v1/app.conf /srv/releases/v1/app.conf.moved
cat /srv/live/pinned.conf
cat /srv/live/current.conf
cat <&3

rm /srv/releases/v1/app.conf.moved /srv/live/pinned.conf
cat <&3
exec 3<&-

Sebelum penggantian nama, path rilis dan pinned.conf menunjukkan inode yang sama dan hard-link count bernilai dua. readlink mencetak payload symlink. stat biasa mengikuti symlink ke target, sedangkan inspeksi non-following pada contoh melaporkan objek symbolic link itu sendiri.

Langkah 3: Prediksikan perilaku rename

mv di dalam filesystem ini menggunakan operasi rename untuk entri sumber. Inode tidak berpindah, sehingga pinned.conf dan descriptor 3 terus berfungsi. current.conf masih menyimpan ../releases/v1/app.conf; karena nama lama tersebut sudah tidak ada, melakukan dereference sekarang akan gagal. Mengubah nama symlink itu sendiri akan memindahkan objek link tersebut, bukan targetnya, dan dapat mengubah arti dari relative payload karena resolusi dimulai dari direktori baru yang memuat link tersebut.

Jika deployment perlu mengalihkan current tanpa jeda nama yang hilang (missing-name interval), buat symlink sementara yang telah disiapkan sepenuhnya di direktori yang sama dan ganti current dengan rename. Pembaca yang membuka setelah penggantian akan me-resolve entri direktori lama atau baru. Proses yang telah membuka target lama tetap memegang descriptor lama mereka.

Langkah 4: Prediksikan unlink dan reklamasi

Menghapus app.conf.moved menurunkan satu hard link. pinned.conf masih menamai inode tersebut, sehingga datanya tetap ada. Menghapus pinned.conf menghilangkan entri direktori terakhir, tetapi descriptor 3 masih memegang referensi terbuka; cat <&3 terus membaca file. Penyimpanan baru dapat direklamasi hanya setelah hard link terakhir dan referensi terbuka terakhir hilang.

Ini menjelaskan mengapa menghapus file log aktif yang besar mungkin tidak membebaskan ruang disk, tetapi ini bukan alasan untuk men-truncate sembarang descriptor. Pertama, identifikasi proses pemilik dan kontrak rotasinya, lalu beri sinyal atau restart proses tersebut secara aman jika diperlukan.

Langkah 5: Terapkan batasan filesystem dan direktori

Nomor inode hanya unik di dalam filesystem-nya sendiri. Hard link tidak dapat menamai inode tersebut dari filesystem lain dan link mengembalikan EXDEV. Symlink dapat menyimpan path yang melintasi batas mount karena pencarian me-resolve nama pada saat akses. Symlink juga dapat menamai direktori atau target yang belum ada.

Linux mencegah hard link biasa ke direktori untuk menghindari siklus (cycle) dan ambiguitas traversal. Symlink ke direktori diizinkan, tetapi memindahkan symlink relatif dapat merusaknya dan tool rekursif mungkin memilih kebijakan follow yang berbeda. Nyatakan kebijakan tersebut untuk tool backup, penghapusan, dan deployment.

Langkah 6: Pilih berdasarkan invarian

Gunakan hard link ketika invarian-nya adalah “nama tambahan ini harus menjaga inode persis tetap dapat dijangkau,” objek-objek tersebut berbagi satu filesystem, dan metadata bersama memang diinginkan. Gunakan symlink ketika invarian-nya adalah “resolve alias ini ke path apa pun yang saat ini disimpannya,” terutama untuk direktori, pointer rilis, atau nama lintas-filesystem. Gunakan salinan (copy) ketika byte, metadata, retensi, atau penempatan filesystem yang independen diperlukan.

Kedua jenis link tersebut bukanlah backup dengan sendirinya. Nama-nama yang di-hard link berbagi mutasi dan korupsi. Symlink tidak berisi data target. Sebuah backup memerlukan batasan kegagalan dan retensi yang independen serta pengujian pemulihan (restore testing).

Langkah 7: Verifikasi identitas dan traversal yang aman

Bandingkan device dan inode, jangan inode saja, karena nomor inode dapat berulang pada filesystem yang berbeda. Periksa hard-link count dengan stat, periksa symlink itu sendiri dengan perilaku bergaya lstat, cetak payload-nya dengan readlink, dan uji urutan rename/unlink yang tepat saat sebuah descriptor sedang terbuka.

Untuk path yang tidak tepercaya, lstat(path) yang diikuti oleh open(path) memungkinkan penyerang mengganti komponen di antara kedua pemanggilan tersebut. Di Linux, buka secara relatif terhadap descriptor direktori tepercaya dan terapkan batasan resolusi openat2 yang diperlukan, seperti melarang symlink atau keluar dari direktori (escape above). Keamanan harus ditegakkan oleh lookup yang mengembalikan descriptor tersebut.

Contoh Jawaban yang Kuat

“Saya mulai dari entri direktori. app.conf dan pinned.conf adalah dua nama yang setara untuk satu inode, sehingga keduanya berbagi konten, izin (permissions), kepemilikan, dan timestamp. current.conf adalah inode symlink terpisah yang payload-nya adalah ../releases/v1/app.conf. Path relatif dimulai dari /srv/live, tempat symlink tersebut berada.

Setelah mengubah nama path rilis, hard link dan descriptor yang sudah terbuka masih mereferensikan objek file yang sama. Symlink menjadi dangling karena pathname yang disimpannya masih menamai entri lama. Setelah menghapus nama yang dipindahkan, hard link menjaga objek tetap hidup. Setelah hard link juga dihapus, descriptor yang terbuka masih berfungsi; kernel baru dapat mereklamasi objek tersebut saat descriptor ditutup.

Saya akan menggunakan hard link untuk mematok artefak persis pada filesystem yang sama, symlink untuk alias current yang dapat dipindahkan, dan salinan nyata untuk retensi independen. Saya akan memperbarui current dengan membuat symlink sementara dan mengubah namanya secara atomik di direktori yang sama. Saya akan membuktikan hasilnya dengan device/inode, link count, readlink, akses dangling-link, dan pengujian open-descriptor. Jika path tidak tepercaya, saya akan menegakkan aturan tanpa-symlink dan batasan direktori selama operasi open itu sendiri.”

Kesalahan Umum

• Menyebut hard link sebagai pointer ke nama asli → semua hard link adalah entri direktori yang setara (peer) untuk satu inode → jelaskan nama, identitas inode, dan link count.
• Mengatakan penghapusan selalu menghancurkan file secara langsung → nama lain atau referensi terbuka mungkin masih ada → telusuri hard-link count dan open descriptor.
• Menganggap symlink sebagai referensi inode yang tersimpan → symlink menyimpan pathname yang nantinya dapat di-resolve secara berbeda atau gagal → periksa payload dan basis resolusi.
• Membandingkan nomor inode tanpa identitas device → nomor inode hanya bersifat lokal pada filesystem → bandingkan device ditambah inode.
• Menggunakan hard link lintas-mount atau untuk direktori → Linux menolak kasus-kasus tersebut → gunakan symlink atau salinan sesuai dengan independensi yang dibutuhkan.
• Memindahkan relative symlink tanpa mengevaluasinya kembali → direktori yang memuatnya menentukan basis resolusi → hitung ulang atau buat ulang target setelah relokasi.
• Menyebut salah satu link sebagai backup → satu berbagi objek dan yang lain hanya menyimpan path → buat salinan yang dapat dipulihkan secara independen.
• Memeriksa path lalu membukanya kemudian → penyerang dapat menukar symlink di antara operasi → tegakkan batasan traversal secara atomik selama operasi open.

Pertanyaan dan Jawaban Lanjutan

Lanjutan 1: Apakah hard link memiliki izin atau pemilik yang terpisah?

Tidak. Izin, pemilik, ukuran, dan timestamp milik inode bersama. Mengubahnya melalui satu hard link akan mengubah apa yang dilihat oleh setiap peer. Nama entri direktori dan izin direktori induknya terpisah; mengubah nama atau meng-unlink nama diatur oleh direktori yang memuatnya.

Lanjutan 2: Mengapa relative symlink terkadang rusak setelah dipindahkan?

Payload-nya diinterpretasikan relatif terhadap direktori yang memuat symlink tersebut. Memindahkan link akan mengubah basis tersebut sembari mempertahankan string yang tersimpan. Symlink absolut mempertahankan satu pathname tetapi bisa salah di dalam container, chroot, mount alternatif, atau host lain. Tentukan pilihan setelah mendefinisikan kebutuhan relokasi.

Lanjutan 3: Bisakah rename menggantikan current secara atomik lintas filesystem?

Tidak. rename pada Linux mengembalikan EXDEV lintas filesystem ter-mount. Publikasikan target yang telah selesai di dalam filesystem tujuan, buat alias sementara di sana, lalu ubah nama alias tersebut menimpa current di direktori yang sama. Tentukan pembersihan dan pemulihan untuk tahap penyalinan sebelumnya.

Lanjutan 4: Mengapa ruang disk tetap terpakai setelah pathname terakhir dihapus?

Sebuah open file description mungkin masih mereferensikan inode tersebut. Temukan descriptor dan proses pemiliknya, lalu gunakan prosedur rotasi atau restart yang aman dari aplikasi. Ruang disk direklamasi setelah nama terakhir dan referensi terbuka terakhir hilang; menghapus pathname saja hanya membuktikan bahwa nama tersebut telah tiada.

Lanjutan 5: Apa perbedaan antara stat, lstat, dan readlink?

stat biasanya mengikuti symlink akhir dan melaporkan targetnya. lstat melaporkan objek symlink itu sendiri. readlink mengembalikan pathname yang disimpannya tanpa me-resolve-nya. Gunakan ketiga konsep ini saat membuktikan alias sekaligus objek yang saat ini dijangkaunya.

Lanjutan 6: Bagaimana Anda mencegah race condition symlink di direktori upload?

Buka secara relatif terhadap descriptor direktori yang tepercaya dan pastikan pencarian memberlakukan aturan bahwa akses tetap berada di bawah direktori tersebut dan tidak mengikuti symlink yang dilarang. Kemudian validasi descriptor yang dikembalikan dengan operasi berbasis descriptor. Pemeriksaan pathname yang diikuti oleh operasi open terpisah menyisakan celah waktu untuk penggantian (replacement window).