Linux'da Kullanıcı Hesapları ve Yetkileri: Sudo ve Su Komutları

sudo ile su dışarıdan bakınca aynı işi yapar: ikisi de sizi root yapar. Ama biri sizin parolanızı sorar, diğeri root’un parolasını — ve Ubuntu gibi dağıtımlarda root’un parolası hiç ayarlanmadığı için ikincisi hiçbir zaman çalışmaz. su: Authentication failure hatasının sebebi yanlış yazdığınız parola değildir; öyle bir parola yoktur.

Bu yazıda ikisinin arasındaki farkı, yetkinin aslında nerede tanımlandığını (/etc/sudoers) ve root kabuğu açmanın neyi kaybettirdiğini göreceğiz.

Kim Olduğunuzu Görmek: id ve UID Aralıkları

Her kullanıcının bir UID‘si, bir birincil GID‘si ve üyesi olduğu ek gruplar vardır. Hepsini tek komutla görürsünüz:

id
# uid=1000(murat) gid=1000(murat) groups=1000(murat),27(sudo)

UID yalnızca bir numara değil, bir sınıflandırmadır:

Sınırın nerede olduğu /etc/login.defs dosyasında yazar:

grep -E '^UID_MIN|^SYS_UID_MAX' /etc/login.defs
# UID_MIN    1000
# SYS_UID_MAX 999

Yukarıdaki id çıktısında dikkat edilecek yer 27(sudo) grubudur — bu kullanıcının root yetkisi alabilmesinin sebebi odur, birazdan göreceğiz.

sudo: Kendi Parolanızla Tek Komut

sudo (superuser do), tek bir komutu başka bir kullanıcının — varsayılan olarak root’un — yetkisiyle çalıştırır. Sorduğu parola sizin parolanızdır, root’unki değil:

sudo systemctl restart nginx
# [sudo] password for murat:

Parolayı her komutta yeniden yazmazsınız: sudo başarılı doğrulamayı bir süre saklar (varsayılan 5 dakika, terminal başına). Süreyi sıfırlayıp bir sonraki komutta yeniden sorulmasını istiyorsanız:

sudo -k        # saklanan doğrulamayı unut

Neye yetkiniz olduğunu tahmin etmek yerine sorabilirsiniz:

sudo -l
# User murat may run the following commands on ubuntu:
#     (ALL : ALL) ALL

(ALL : ALL) ALL “her kullanıcı ve her grup adına, her komutu” demektir. Kısıtlı bir yapılandırmada burada yalnızca izin verilen komutlar listelenir — bir işlem sudo ile de reddediliyorsa ilk bakılacak yer bu çıktıdır.

Yetkiyi Kim Veriyor: /etc/sudoers ve visudo

sudo yetkisi kullanıcının kendisine değil, çoğunlukla bir gruba verilir. Grubun adı dağıtıma göre değişir:

Yani bir kullanıcıya sudo yetkisi vermek, aslında onu doğru gruba eklemektir:

sudo usermod -aG sudo murat     # Debian/Ubuntu
sudo usermod -aG wheel murat    # RHEL ailesi / Arch

-aG‘yi tek kalıp olarak yazın: -a olmadan usermod -G, kullanıcının diğer tüm ek gruplarını siler. Ayrıntısı gruplar yazısında.

/etc/sudoers‘ı asla doğrudan düzenlemeyin. Dosyada tek bir sözdizimi hatası sudo‘yu tamamen çalışmaz hâle getirir; root parolası da yoksa sisteme yönetici olarak girmenin hiçbir yolu kalmaz ve kurtarma kipiyle açmak zorunda kalırsınız. Doğru araç visudo‘dur: dosyayı geçici bir kopya üzerinde açar, kaydederken sözdizimini denetler ve hatalıysa yazmayı reddeder.

sudo visudo                          # /etc/sudoers
sudo visudo -f /etc/sudoers.d/murat  # ayrı bir kural dosyası (tercih edilen yol)

Yeni kuralları /etc/sudoers.d/ altına ayrı dosya olarak koymak daha güvenlidir: dağıtım güncellemesi ana dosyayı değiştirdiğinde sizin kuralınız etkilenmez.

su: Kimlik Değiştirmek — ve Tirenin Farkı

su (switch user) yetki yükseltmez, kimlik değiştirir. Hedef kullanıcının parolasını ister:

su - ayse         # ayse'nin parolası sorulur
su -              # root'un parolası sorulur

Tire süs değildir. su ayse kimliği değiştirir ama kabuğu oturum açma kabuğu yapmaz: su(1)‘in geriye dönük uyumluluk için koruduğu varsayılan davranış, çalışma dizinini değiştirmemek ve yalnızca HOME ile SHELL‘i (hedef root değilse ayrıca USER ve LOGNAME) ayarlamaktır. PATH sizinki kalır, hedef kullanıcının ~/.bash_profile dosyası okunmaz. su - ayse ise tam bir oturum açar — ev dizinine geçer, ortamı sıfırdan kurar. Bir komutun “bulunamadığı” durumların büyük kısmı bu tireyi unutmaktan gelir.

su - çoğu Ubuntu ve Debian kurulumunda çalışmaz:

su -
# Password:
# su: Authentication failure

Sebep, kurulum sırasında root hesabına parola verilmemesidir. Parola alanı /etc/shadow içinde geçerli bir hash yerine ! ya da * taşır; shadow(5)‘e göre hiçbir parola böyle bir değerle eşleşemez, yani hesapla parolayla oturum açılamaz. Bu bilinçli bir tasarımdır: root’a doğrudan girilmesin, yetki sudo üzerinden ve iz bırakarak alınsın diye. Root kabuğuna gerçekten ihtiyacınız varsa doğru yol sudo -i‘dir.

sudo -i, sudo -s, su - : Hangi Ortamı Alırsınız

Üçü de size root kabuğu verir; farkları hangi ortam değişkenleriyle açıldıklarıdır:

Tabloda olmayan ama üçü için de geçerli olan bir şey var: hiçbiri size kendi PATH‘inizi vermez. sudo komutu sıfırlanmış bir ortamda çalıştırır (env_reset varsayılan olarak açıktır) ve sudoers içinde secure_path tanımlıysa PATH‘in yerine onun değeri geçer. Ubuntu bunu varsayılan olarak tanımlar:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Isırdığı yer burasıdır: ~/.local/bin ya da /opt/... altına kurduğunuz bir aracı kendi kabuğunuzda çalıştırabilirsiniz, ama sudo arac “command not found” der — o dizin secure_path içinde değildir. Ne yaptığınızı sudo -l çıktısının başındaki Matching Defaults entries satırından görürsünüz; çözüm ya tam yol yazmak (sudo /opt/arac/bin/arac) ya da visudo ile secure_path‘i genişletmektir. Aynı sebeple kendi takma adlarınız da sudo altında çalışmaz.

Kural basittir: root olarak temiz ve öngörülebilir bir ortam istiyorsanız sudo -i, bulunduğunuz dizinden ayrılmak istemediğiniz kısa bir iş için sudo -s.

Root Kabuğu Açmak İzi Kaybettirir

sudo‘nun parola sormaktan daha önemli bir işlevi vardır: her çağrıyı kaydeder. Kim, ne zaman, hangi dizinde, hangi komutu çalıştırdı — hepsi günlüğe yazılır:

journalctl -t sudo --since today
# sudo[2411]: murat : TTY=pts/0 ; PWD=/home/murat ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

Günlüğün yeri dağıtıma göre değişir: Debian/Ubuntu’da /var/log/auth.log, RHEL ailesinde /var/log/secure, yalnızca systemd journal kullanan Arch ve Fedora’da ise böyle bir dosya yoktur — yukarıdaki journalctl komutu her üçünde de çalışır.

Şimdi asıl mesele: sudo -i ile bir root kabuğu açtığınızda günlüğe yalnızca o tek satır yazılır. O kabuğun içinde yüz komut çalıştırsanız da hiçbiri kaydedilmez, çünkü artık sudo devrede değildir.

sudo -i
# günlükte tek kayıt: COMMAND=/bin/bash
# ...bundan sonra yaptığınız hiçbir şey görünmez

Tek başına çalıştığınız bir makinede bu önemsiz olabilir. Birden fazla yöneticinin girdiği bir sunucuda ise bir sorunun ne zaman ve kim tarafından çıkarıldığını bulmanın tek yolu bu günlüktür. Alışkanlığınız sudo komut olsun; root kabuğu, gerçekten arka arkaya çok sayıda ayrıcalıklı komut çalıştıracağınız durumlar için ayrılsın.

Sonuç

• sudo yetki yükseltir, su kimlik değiştirir. İlkinde kendi parolanızla tek bir komutu root olarak çalıştırırsınız; ikincisinde hedef kullanıcının parolasıyla tamamen o kullanıcı olursunuz.
• sudo -i oturum açar, sudo -s yalnızca kabuk açar. İlki root’un başlangıç dosyalarını okuyup /root‘a geçer, ikincisi bulunduğunuz dizinde kalır; ikisinde de PATH‘iniz secure_path ile değiştirilir — bir komut sudo altında bulunamıyorsa önce oraya bakın.
• Root kabuğu açmak, sudo‘nun bıraktığı izi kaybettirir. Her sudo komut çağrısı günlüğe yazılır; sudo -i ile açtığınız oturumun içinde ne yaptığınız yazılmaz.

Yol haritasında sırada hesabı fiilen oluşturmak var: Yeni Kullanıcılar Oluşturma ve Silme. Serinin tamamına GNU/Linux Öğrenme Yolculuğu sayfasından ulaşabilirsiniz.