Kodeloka
  1. Kodeloka
  2. Kelas Linux & Shell
  3. Materi

1 · Fondasi · Modul 2 dari 8

Izin, Kepemilikan & sudo

Model izin Linux yang menjelaskan mayoritas error 'Permission denied', termasuk di dalam kontainer.

Membaca Keluaran ls -l

-rw-r--r--  1 budi  tim   4096 Jul 28 10:15 catatan.txt
drwxr-xr-x  2 budi  tim   4096 Jul 28 10:15 proyek/
│└┬┘└┬┘└┬┘
│ │  │  └── lainnya (others)
│ │  └───── grup
│ └──────── pemilik
└────────── jenis: - berkas, d direktori, l symlink
SimbolPada berkasPada direktori
r (4)Boleh membaca isiBoleh melihat daftar isinya
w (2)Boleh mengubah isiBoleh membuat/menghapus berkas di dalamnya
x (1)Boleh dijalankanBoleh masuk ke dalamnya
⚠️ Arti x pada direktori sering disalahpahami

Pada direktori, x bukan berarti "dapat dieksekusi" melainkan dapat dilewati. Tanpa x, Anda tidak bisa masuk ke direktori itu maupun mengakses apa pun di dalamnya — bahkan bila berkas di dalamnya berizin 777.

Sebaliknya, direktori dengan x tapi tanpa r membuat Anda bisa membuka berkas yang namanya sudah Anda ketahui, tetapi tidak bisa melihat daftar isinya. Ini kadang dipakai secara sengaja.

Mengubah Izin

chmod 644 berkas.txt        # rw- r-- r--
chmod 755 skrip.sh          # rwx r-x r-x
chmod 600 ~/.ssh/id_rsa     # rw- --- ---  (WAJIB untuk kunci privat)

# Bentuk simbolik, lebih terbaca
chmod u+x skrip.sh          # pemilik boleh eksekusi
chmod go-w berkas           # cabut tulis dari grup & lainnya
chmod -R u+rwX,go-rwx rahasia/   # X = x hanya untuk direktori

chown budi:tim berkas
chown -R www-data:www-data /var/www
🚫 chmod 777 hampir tidak pernah merupakan jawaban

Ketika ada error izin, mengubah semuanya menjadi 777 memang menghilangkan pesan errornya — sekaligus mengizinkan siapa pun di sistem itu membaca, mengubah, dan menjalankan berkas tersebut. Pada server bersama atau kontainer yang diretas, ini menjadi jalan masuk yang lebar.

Alih-alih itu, cari tahu pengguna mana yang menjalankan proses tersebut, lalu berikan kepemilikan atau keanggotaan grup yang tepat. Untuk kunci SSH, izin yang terlalu longgar bahkan membuat OpenSSH menolak memakainya — itu fitur, bukan bug.

umask: Izin Bawaan

umask                     # biasanya 0022

# Berkas baru : 666 - 022 = 644
# Direktori   : 777 - 022 = 755

umask 077                 # berkas baru hanya untuk pemilik (600)

Bit Khusus

chmod u+s program         # setuid  — jalan sebagai PEMILIK berkas
chmod g+s direktori       # setgid  — berkas baru mewarisi grup direktori
chmod +t /tmp             # sticky  — hanya pemilik boleh hapus berkasnya

ls -l /usr/bin/passwd
# -rwsr-xr-x  ← huruf s: berjalan sebagai root meski dipanggil pengguna biasa
🚫 setuid adalah target eskalasi hak akses klasik

Program ber-setuid milik root berjalan dengan hak root siapa pun yang menjalankannya. Bila program itu punya celah, penyerang mendapat root. Ini vektor serangan yang sangat sering dipakai.

# Audit: cari semua program setuid di sistem
find / -perm -4000 -type f 2>/dev/null

Di dalam kontainer, buang kemampuan ini sepenuhnya dengan --security-opt=no-new-privileges atau allowPrivilegeEscalation: false di Kubernetes.

sudo

sudo perintah             # jalankan sebagai root
sudo -u www-data perintah # jalankan sebagai pengguna lain
sudo -i                   # shell root penuh
sudo -l                   # apa saja yang boleh saya jalankan

# /etc/sudoers.d/deploy — JANGAN sunting /etc/sudoers langsung
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart aplikasi
deploy ALL=(ALL) NOPASSWD: /usr/bin/docker compose -f /srv/app/compose.yaml up -d
📌 Selalu pakai visudo

Kesalahan sintaks pada berkas sudoers dapat mengunci semua orang dari akses root, dan memperbaikinya memerlukan boot ke mode penyelamatan. Perintah visudo memvalidasi berkas sebelum menyimpannya:

sudo visudo -f /etc/sudoers.d/deploy

Beri izin sudo sesempit mungkin — daftar perintah spesifik, bukan ALL. Perhatikan juga bahwa mengizinkan perintah yang bisa memanggil shell (seperti vim atau less) sama saja memberi akses root penuh.