Permission Errors

Pesan Permission denied adalah cara Linux bertanya dengan sopan: siapa Anda, dan apa yang Anda minta? Sayangnya, refleksi pertama banyak pengguna adalah menyerah pada chmod -R 777 — perintah yang menyelesaikan gejala hari ini dengan membuat masalah keamanan tahun depan. Chapter ini melatih kebiasaan yang benar: membaca pesannya dengan teliti, mendiagnosis siapa kita dan apa yang diminta aksesnya, lalu memperbaiki kepemilikan dengan alat yang tepat. Anatomi tiga digit permission sendiri sudah dibedah tuntas di Chapter File Permissions .

Membaca Pesan dengan Teliti #

Dua pesan yang berbeda sering disamakan padahal solusinya berlawanan. Perhatikan dua kegagalan berikut:

mkdir -p latihan
mkdir latihan/anak/cucu 2>&1
printf 'data penting\n' > rahasia.txt
chmod 000 rahasia.txt
cat rahasia.txt 2>&1

Output yang Dihasilkan:

mkdir: cannot create directory ‘latihan/anak/cucu’: No such file or directory
cat: rahasia.txt: Permission denied

Pesan pertama menyebut No such file or directory — induk direktorinya belum ada, dan solusinya mkdir -p; ini bukan masalah permission sama sekali. Pesan kedua menyebut Permission denied pada berkas yang jelas ada — pemiliknya memang meniadakan semua hak aksesnya dengan chmod 000. Kebiasaannya satu: baca sampai akhir, karena kalimat terakhir pesan selalu menyebut objek dan alasannya.

Diagnosis: Siapa Kita dan Apa yang Diminta #

Tiga perintah baca-saja menjawab hampir semua pertanyaan permission. id menampilkan user, uid, dan daftar group kita — hak akses selalu dievaluasi terhadap identitas ini. stat -c '%U %G %a %n' berkas menampilkan pemilik, group, dan permission berkas target dalam satu baris. namei -l /jalur/panjang membedah setiap tingkat jalur beserta permissionnya — berguna saat path dalam berarti gagal di tengah jalan. Setelah identitas kedua pihak terbaca, perbaikannya baru ditentukan. Kita praktikkan pada kasus rahasia.txt tadi:

printf 'data penting\n' > rahasia.txt
chmod 000 rahasia.txt
stat -c '%a %n' rahasia.txt
chmod 644 rahasia.txt
cat rahasia.txt

Output yang Dihasilkan:

0 rahasia.txt
data penting

Diagnosis menunjukkan angka 0 — stat mencetak oktal tanpa nol di depan, jadi 000 tampil sebagai 0: pemilik tidak punya hak baca, tulis, maupun eksekusi. Perbaikannya mengembalikan hak baca yang wajar: chmod 644 untuk berkas biasa. cat kini menjawab dengan isi berkasnya. Pola diagnosis-perbaikan-uji ini persis prosedur empat langkah dari Chapter chmod dan chown .

Kasus: Bit x pada Direktori #

Direktori menafsirkan permission berbeda dari berkas: r berarti boleh melihat daftar isi, sedangkan x berarti boleh menelusuri — masuk ke dalamnya dan mengakses apa pun di bawahnya. Karena itu berkas yang tampak “baik-baik saja” bisa tetap tak terbaca bila salah satu direktori di jalurnya kehilangan bit x:

mkdir -p arsip
printf 'isi\n' > arsip/catatan.txt
chmod a-x arsip
cat arsip/catatan.txt 2>&1 || echo "-> butuh bit x untuk menelusuri direktori"
chmod 755 arsip
cat arsip/catatan.txt

Output yang Dihasilkan:

cat: arsip/catatan.txt: Permission denied
-> butuh bit x untuk menelusuri direktori
isi

Hak baca berkas catatan.txt tidak pernah diubah — yang hilang adalah hak menelusuri direktori arsip, dan chmod 755 mengembalikannya. Pola umumnya: pesan menunjuk berkas, tetapi tersangkanya sering direktori di jalurnya; namei -l memperlihatkan tingkat mana yang bermasalah.

Kasus: SSH Menolak Kunci karena Terlalu Longgar #

Kasus ini kebalikan intuisi pemula: SSH menolak kunci karena permissionnya terlalu terbuka, bukan terlalu ketat. Server dan client memang menuntut ~/.ssh bernilai 700 dan kunci privat bernilai 600 — kunci privat yang bisa dibaca user lain dianggap bocor:

mkdir -p .ssh
printf 'ssh-ed25519 AAAAContohKunci budi@laptop-budi\n' > .ssh/id_ed25519.pub
chmod 700 .ssh
chmod 600 .ssh/id_ed25519.pub
stat -c '%a %n' .ssh .ssh/id_ed25519.pub

Output yang Dihasilkan:

700 .ssh
600 .ssh/id_ed25519.pub

Bila klien mengeluh WARNING: UNPROTECTED PRIVATE KEY FILE!, perbaiki dengan mengencangkan — chmod 600 ~/.ssh/id_ed25519 — bukan melonggarkan. Mekanisme autentikasi kunci dibedah di Chapter SSH Keys dan Agent .

Mengapa chmod -R 777 Itu Jerat #

Angka 777 memberi hak baca-tulis-eksekusi kepada semua user di sistem. Untuk berkas milik web server, itu berarti user apa pun — termasuk akun layanan yang diretas — boleh menimpa isinya. Solusi yang benar hampir selalu satu dari tiga: pindahkan kepemilikan ke user yang tepat dengan chown, tambahkan user ke group yang sudah memegang hak akses dengan usermod -aG (group dikelola seperti di Chapter Group Management ), atau pakai ACL bila dua pihak berbeda butuh akses berbeda — topik Chapter Access Control Lists .

Tabel Gejala, Konteks, dan Solusi #

Perhatikan bahwa tidak satu pun baris tabel itu berisi 777. Membaca pesan, mengenali konteks, lalu memperbaiki kepemilikan — itulah seluruh pola kerjanya. Ada satu jenis pesan penolakan yang gejalanya mirip padahal bukan permission: koneksi yang tidak kunjung terjawab. Kita tutup rangkaian perbaikan dasar ini dengan membedah koneksi yang bermasalah di Chapter Network Connection Issues .

Referensi lanjut: chmod(1) dan stat(1) untuk seluruh opsi kedua alat diagnosis.