whoami Komutu: Kullanici Kimligi ve Oturum Bilgisi
Sysadmin hayatinda bazen en basit sorular en kritik olanlaridir: “Ben simdi hangi kullanici olarak calisiyorum?” Bu soruyu gunde en az 10 kez soruyorsaniz, yanit cok basit: whoami komutu. Ama bu kucuk komutun arkasinda duran kavramlar, ozellikle production ortamlarinda, sandıginizdan cok daha derin.
Bu yazida whoami komutunu bastan sona ele alacagiz. Hem Linux hem Windows tarafina bakacagiz, gercek dunya senaryolariyla pekistireceğiz ve bu komutu gunluk is akisiniza nasil entegre edebileceginizi gosterecegiz.
whoami Nedir ve Neden Vardir?
whoami komutu, adindan da anlasilacagi uzere “Ben kimim?” sorusunu yanıtlar. Calistiran kullanicinin efektif kullanici adini standart ciktiya yazar. Kullanisi son derece basittir ama anlamak icin biraz arka plana ihtiyac var.
Linux sistemlerde her prosesin iki katmanli bir kimlik yapisi vardir:
- Real User ID (RUID): Prosesi baslatan gercek kullanici
- Effective User ID (EUID): Prosesin o an sahip oldugu yetkiler icin kullanilan kimlik
whoami komutu EUID’yi gosterir. Bu neden onemli? Cunku sudo veya su gibi komutlarla baska bir kullaniciya gectiginde, RUID degismez ama EUID degisir. whoami sana o an hangi yetkilerle calistigini soyleyen komuttur.
Temel Kullanim
Komutun kullanimi sadeligiyle ovunur:
whoami
Cikti sadece kullanici adinizdir:
ahmet
Ya da root olarak calisiyorsaniz:
root
Parametrelere bakacak olursak, whoami komutunun cok az secenegi vardir:
# Yardim mesajini goster
whoami --help
# Surum bilgisini goster
whoami --version
Bu kadar. Ama guc bu sadeliktedir zaten.
id Komutu ile Karsilastirma
whoami tek basina guzel bir araç ama tam resmi gormek icin id komutuyla birlikte kullanilmasi gerekir. id komutu cok daha fazla bilgi sunar:
id
Ornek cikti:
uid=1001(ahmet) gid=1001(ahmet) groups=1001(ahmet),27(sudo),999(docker),1002(developers)
Burada gorulen bilgiler:
- uid: Kullanici numarasi ve adi
- gid: Ana grup numarasi ve adi
- groups: Kullanicinin ait oldugu tum gruplar
Belirli bir kullanici hakkinda bilgi almak icin:
id nginx
# uid=33(www-data) gid=33(www-data) groups=33(www-data)
id postgres
# uid=113(postgres) gid=117(postgres) groups=117(postgres),116(ssl-cert)
whoami sadece o an aktif kullanici adini verirken, id tum kimlik bilgilerini detaylandırır. Scripting yaparken ikisini birlikte kullanmak en saglikli yaklasimdir.
Gercek Dunya Senaryosu 1: Script Basinda Kimlik Kontrolu
Production ortaminda calistirdigimiz script’lerin dogru kullanici olarak calisip calismadigini kontrol etmek kritik bir pratiktir. Bir backup script’i dusunun: root olarak calismazsa kritik dosyalara erismeyecektir. Ama root olarak hatayla calisirsa farkli bir kaos ortaya cikar.
#!/bin/bash
# Script basinda kullanici kontrolu
CURRENT_USER=$(whoami)
REQUIRED_USER="backup_agent"
if [ "$CURRENT_USER" != "$REQUIRED_USER" ]; then
echo "HATA: Bu script '$REQUIRED_USER' kullanicisi olarak calistirilmalidir."
echo "Simdi calistiran kullanici: $CURRENT_USER"
echo "Kullanim: sudo -u $REQUIRED_USER $0"
exit 1
fi
echo "Kimlik dogrulandi: $CURRENT_USER"
echo "Backup islemi basliyor..."
# Backup islemleri buraya gelir
rsync -avz /var/data/ /mnt/backup/
Bu pattern’i her kritik script’in basina koymak, “Neden calismiyor?” seklindeki debug seanslarini buyuk olcude azaltir.
Sudo ile Kimlik Degisimi
sudo kullandigimizda kimligimiz nasil degisiyor? Bunu anlamak icin kucuk bir deney yapalim:
# Normal kullanici olarak
whoami
# ahmet
# sudo ile tek komut
sudo whoami
# root
# Sudo shell'e gecis
sudo -i
whoami
# root
# sudo -u ile baska kullaniciya gecis
sudo -u postgres whoami
# postgres
# Exit ile geri don
exit
whoami
# ahmet
Burada dikkat edilmesi gereken bir nokta var: sudo -i veya sudo su - ile root’a gectigimizde sadece whoami degismez, ortam degiskenleri de tamamen degisir. HOME, PATH, SHELL gibi degiskenler root kullanicisina gore ayarlanir. Bu bazen script’lerin beklendik sekilde davranmamasina yol acar.
Windows Tarafinda whoami
Windows dunyasinda da whoami komutu bulunur ve hem CMD hem PowerShell’de calisir. Ama Linux’takinden cok daha zengin ozelliklere sahiptir.
REM Temel kullanim - CMD
whoami
REM Cikti: SUNUCU01ahmet ya da DOMAINahmet
REM Tam bilgi
whoami /all
REM Sadece grup bilgileri
whoami /groups
REM Sadece yetki bilgileri
whoami /priv
PowerShell tarafinda ise su sekilde kullanilir:
# Temel kullanim
whoami
# DOMAINkullanici
# Detayli bilgi
whoami /all
# Sadece kullanici bilgisi
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
# DOMAINkullanici
# Administrator kontrolu
$currentPrincipal = [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
$isAdmin = $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
Write-Host "Admin yetkisi var mi: $isAdmin"
Windows’ta whoami /priv ciktisi ozellikle onemlidir. Bu cikti size o anki kullanicinin hangi Windows ayricaliklarina sahip oldugunu gosterir: SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege gibi. Bir servis hesabinin yetersiz calistigi durumlarda buraya bakmak cok sey anlatir.
Gercek Dunya Senaryosu 2: Cok Kullanicili Sunucu Yonetimi
Birden fazla sysadmin’in calistigi bir ortamda kimin ne yaptigini takip etmek onemlidir. Asagidaki senaryo, bir sunucuya giren her kullanicinin kimligini ve giris zamanini loglayan basit bir mekanizmadir:
#!/bin/bash
# /etc/profile.d/session_logger.sh
# Bu script her login shell'de calisir
LOG_FILE="/var/log/session_tracker.log"
CURRENT_USER=$(whoami)
LOGIN_TIME=$(date '+%Y-%m-%d %H:%M:%S')
REMOTE_IP=${SSH_CLIENT%% *}
HOSTNAME=$(hostname)
# Log kaydi olustur
echo "[$LOGIN_TIME] GIRIS - Kullanici: $CURRENT_USER | IP: ${REMOTE_IP:-lokal} | Sunucu: $HOSTNAME" >> "$LOG_FILE"
# Cikista da log al
trap "echo "[$(date '+%Y-%m-%d %H:%M:%S')] CIKIS - Kullanici: $CURRENT_USER | IP: ${REMOTE_IP:-lokal}" >> $LOG_FILE" EXIT
Bu script’i /etc/profile.d/ altina koydugumuzda her login shell’de otomatik olarak calisir. Log dosyasina baktigimizda kimin ne zaman giris yaptigini ve ne zaman ciktigini gorebilirsiniz.
Gercek Dunya Senaryosu 3: Konteyner Ortaminda Kimlik Sorunlari
Docker ve Kubernetes kullananlar icin kullanici kimligi ayrı bir dert kaynagi olabilir. Bir konteyner icinde kimin calistigini bilmek, dosya izinleri ve guvenlik acisindan kritiktir:
# Konteyner icinde kim olarak calisiyoruz?
docker exec -it uygulama_container whoami
# root <- Bu tehlikeli bir durum!
# Konteyner'i belirli kullanici ile calistir
docker run --user 1001:1001 nginx whoami
# nobody
# Dockerfile'da kullanici tanimlama
# FROM ubuntu:22.04
# RUN useradd -m -u 1001 appuser
# USER appuser
# CMD whoami # -> appuser
# Calistiran kullaniciyi kontrol ederek guvenlik onlemi
docker exec uygulama_container bash -c '
CONTAINER_USER=$(whoami)
if [ "$CONTAINER_USER" = "root" ]; then
echo "UYARI: Konteyner root olarak calisiyor! Guvenlik riski!"
exit 1
fi
echo "Guvenli: Konteyner $CONTAINER_USER olarak calisiyor"
'
Uretim ortaminda konteynerlerin root olarak calmasi buyuk bir guvenlik acigi olusturur. Bu nedenle deployment pipeline’larina whoami kontrolu eklemek iyi bir pratiktir.
Ortam Degiskenleri ile Birlikte Kullanim
whoami ciktisini baska komutlarla birlestirebiliriz. Ozellikle dinamik dizin ve dosya yolu olusturma senaryolarinda kullanislidir:
#!/bin/bash
# Kullaniciya ozel log dizini olustur
CURRENT_USER=$(whoami)
USER_LOG_DIR="/var/log/app_logs/${CURRENT_USER}"
# Dizin yoksa olustur
if [ ! -d "$USER_LOG_DIR" ]; then
mkdir -p "$USER_LOG_DIR"
echo "Log dizini olusturuldu: $USER_LOG_DIR"
fi
# Kullaniciya ozel gecici dosya
TEMP_FILE="/tmp/${CURRENT_USER}_$(date +%s).tmp"
touch "$TEMP_FILE"
echo "Gecici dosya: $TEMP_FILE"
# Kullanici ev dizinini bul
USER_HOME=$(eval echo ~$CURRENT_USER)
echo "Ev dizini: $USER_HOME"
# Config dosyasi olustur
CONFIG_FILE="${USER_HOME}/.app_config"
cat > "$CONFIG_FILE" << EOF
# Otomatik olusturuldu - $(date)
# Kullanici: $CURRENT_USER
LOG_DIR=$USER_LOG_DIR
TEMP_DIR=/tmp/${CURRENT_USER}
EOF
echo "Config dosyasi olusturuldu: $CONFIG_FILE"
who ve w Komutlariyla Tamamlayici Kullanim
whoami tek kullanicinin kimligini gosterirken, who ve w komutlari sisteme girmis tum kullanicilari listeler:
# Sisteme giris yapmis tum kullanicilar
who
# Ornek cikti:
# ahmet pts/0 2024-01-15 09:23 (192.168.1.100)
# mehmet pts/1 2024-01-15 10:45 (192.168.1.105)
# root tty1 2024-01-15 08:00
# Daha detayli bilgi - ne yapiyorlar?
w
# Ornek cikti:
# USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
# ahmet pts/0 192.168.1.100 09:23 0.00s 0.05s 0.00s w
# mehmet pts/1 192.168.1.105 10:45 5:23 0.02s 0.02s vim /etc/nginx/nginx.conf
# Sadece kendi oturumunuz
who am i
# ahmet pts/0 2024-01-15 09:23 (192.168.1.100)
# Kac kullanici var?
who | wc -l
w komutu sistem yoneticileri icin altin degerindedir. Kimin ne yaptigini gorme imkani verir. Birinin nginx config’ini editlerken sizi uyarir, boylece ayni dosyada cakismayi onleyebilirsiniz.
last Komutu ile Gecmis Oturumlara Bakis
Mevcut oturumun otesinde, gecmis oturumlar da sistem guvenliginin izlenmesinde onem tasir:
# Son giris yapanlari listele
last -n 20
# Belirli kullanicinin giris gecmisi
last ahmet
# Basarisiz giris denemelerini goster
lastb
# Son basarili giris
last -n 1 ahmet
# Sistemi en son kimlerin reboot'ladigini gormek
last reboot
Bu komutlari bir araya getirip gunluk sistem saglik kontrolunun parcasi haline getirebilirsiniz.
Gercek Dunya Senaryosu 4: Deployment Scripti Guvenlik Kontrolu
Bir deployment script’inin sadece CI/CD servis kullanicisi tarafindan calistirilabilmesini istiyorsunuz diyelim. Hem whoami hem de ek kontroller iceren kapsamli bir ornek:
#!/bin/bash
set -euo pipefail
# Renk tanimlari
RED='33[0;31m'
GREEN='33[0;32m'
YELLOW='33[1;33m'
NC='33[0m'
# Guvenlik kontrolleri
check_identity() {
local current_user
current_user=$(whoami)
local allowed_users=("deploy_agent" "ci_runner" "jenkins")
local is_allowed=false
for user in "${allowed_users[@]}"; do
if [ "$current_user" = "$user" ]; then
is_allowed=true
break
fi
done
if [ "$is_allowed" = false ]; then
echo -e "${RED}HATA: Yetkisiz kullanici: $current_user${NC}"
echo -e "${YELLOW}Izin verilen kullanicilar: ${allowed_users[*]}${NC}"
exit 1
fi
echo -e "${GREEN}Kimlik dogrulandi: $current_user${NC}"
}
# Root olarak calismayi engelle
check_not_root() {
if [ "$(whoami)" = "root" ]; then
echo -e "${RED}HATA: Bu script root olarak calistirilmamalıdir!${NC}"
exit 1
fi
}
# Sudo yetkisi var mi kontrol et
check_sudo_available() {
if sudo -n true 2>/dev/null; then
echo "Sudo yetkisi mevcut"
else
echo -e "${YELLOW}UYARI: Sudo yetkisi yok, bazi islemler basarisiz olabilir${NC}"
fi
}
# Ana akis
echo "Deployment basliyor..."
check_not_root
check_identity
check_sudo_available
echo "Tum kontroller gecti. Deployment devam ediyor..."
Kisayollar ve Alternatifler
whoami disinda ayni bilgiye ulasmanin baska yollari da vardir. Bunlari bilmek, whoami’nin olmadigi sistemlerde veya script icerisinde farkli kaynaklardan dogrulama yapmaniz gerektiginde ise yarar:
# Ortam degiskeni ile
echo $USER
# ahmet
# Logname ile (login adi, EUID degil RUID getirir)
logname
# ahmet
# /proc uzerinden
cat /proc/self/status | grep "^Name:"
# Proses adi (her zaman kullanici adi vermez)
# id komutu ile sadece kullanici adi
id -un
# ahmet
# Pythondan kullanici adi alma (cross-platform script'lerde)
python3 -c "import getpass; print(getpass.getuser())"
# ahmet
# Bash degiskeni
echo "${USER:-$(id -un)}"
# ahmet
Ozellikle id -un kombinasyonu, whoaminin bazi minimal sistemlerde bulunmadigi durumlarda guvenilir bir alternatiftir.
Sonuc
whoami komutu, gorunuste en basit Linux/Windows komutlarindan biridir. Ama gunluk sysadmin hayatinizda bu kucuk komutun ne kadar merkezi bir rol oynadigini anlattıklarimızdan cıkarmak gerekmez, bizzat yasadikca gorursunuz.
Ozetle su pratikleri benimsemek sizi daha iyi bir sistem yoneticisi yapar:
- Her kritik script’in basina kimlik kontrolu ekleyin
whoamiileidkomutunu birlikte kullanmayi aliskanlik edinin- Sudo ile kimlik gecislerini anlayin ve test edin
- Konteyner ortamlarinda root ile calismamaya ozen gosterin
who,wvelastkomutlarini gunluk rutin incelemenize katin
Bir sistemde “Kim bu islemi yapti?”, “Hangi yetkilerle calisiyorum?” veya “Bu script dogru kullanicida mi calisiyor?” sorularini sormaya basladiginizda, whoami ve onun ekosistemi size her zaman net bir yanit verecektir.
Sistemleriniz saglikli, yetkileriniz dogru tanimlanmis olsun.