whoami Komutu: Linux’ta Kullanici Kimligi ve Oturum Bilgisi

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
  • whoami ile id komutunu birlikte kullanmayi aliskanlik edinin
  • Sudo ile kimlik gecislerini anlayin ve test edin
  • Konteyner ortamlarinda root ile calismamaya ozen gosterin
  • who, w ve last komutlarini 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.

Yorum yapın