← Tüm Yazılar · #linux

Paylaşımlı Linux Workstation'larda Süreli Giriş: PAM, SSSD ve Session Watchdog

AD domain'ine bağlı paylaşımlı Linux workstation'larda rezervasyon tabanlı erişim kontrolü: GPO ve hazır PAM modüllerinin sınırları, kurgulanan mimari ve test ortamında gözlemlenen edge case'ler.

12 October 2026 · 16 dk okuma · 3257 kelime

English version: Time-Boxed Logins on Shared Linux Workstations

Problem

Ortak kullanılan ve Active Directory (AD) domain’ine bağlı Linux workstation’ların bulunduğu ortamlarda kullanıcılar merkezi domain hesaplarıyla oturum açarlar. Bu makineler çoğunlukla yüksek kaynaklı (GPU, bellek, özel lisanslar) olduğu için “ilk gelen alır” mantığıyla işletilmeye uygun değildir. Kullanıcıların belirli bir makineyi belirli bir zaman aralığı için rezerve etmesi beklenir (örneğin ws07 makinesinin salı 09:00 ile perşembe 18:00 aralığında tahsis edilmesi gibi). Böyle bir yapıda sistemin üç temel kuralı tavizsiz işletmesi gerekir:

İlgili makinede o an için geçerli bir rezervasyonu bulunmayan kullanıcılar login olamamalıdır.
Rezervasyon süresi bittiğinde session derhal sonlandırılmalıdır. Bu işlem bir sonraki logout’a ya da birinin fark etmesine bırakılamaz.
Yönetimsel kararlar (süre uzatma, iptal, maintenance modu, hesap engelleme) tek bir merkezden verilmeli ve bir iki dakika içinde client’lara yansımalıdır.

Bu kurallardan ilki admission (kabul), ikincisi eviction (tahliye), üçüncüsü ise single source of truth (doğrunun kimde olduğu) ile ilgilidir. Açık kaynak araçların çoğu admission aşamasını iyi çözmektedir; ancak dinamik bir takvime göre çalışan eviction için neredeyse hiç hazır çözüm bulunmamaktadır. Merkezi yönetim tarafında ise genellikle her host’ta ayrı bir config dosyası düzenlemek zorunda kalınmaktadır.

Bu yazıda; söz konusu ihtiyacı karşılamak üzere kurgulanan mimari (PAM login gate, SSSD, session watchdog servisi, heartbeat ve merkezi rezervasyon API’si), kabul edilen mimari ödünler ve kurulan test ortamında ortaya çıkan edge case’ler ele alınmaktadır.

Hazır Seçenekler ve Sınırları

Herhangi bir geliştirme yapılmadan önce mevcut seçenekler, problemin ihtiyaç duyduğu yedi temel kriter üzerinden incelenmiştir: dinamik rezervasyon desteği, makine bazlı atama, session ortasında süre bitimi, kullanıcıya ön uyarı, merkezden anlık iptal/uzatma imkânı, network kesintisi davranışı ve audit trail (denetim kaydı).

Seçenek	Dinamik rezervasyon	Makineye özel	Session ortasında süre dolması	Önceden uyarı	Merkezden iptal/uzatma	Kesintide davranış	Audit kaydı
AD `logonHours` + GPO, Windows client’lar	Hayır: hesap başına haftalık saat tablosu	OU bazında logon-rights GPO’ları (`userWorkstations` deprecated)	Evet, “Set action to take when logon hours expire” ile (kilitle, bağlantıyı kes, logoff yap)	Evet, bir eylem tanımlıysa	Hesabı ya da GPO’yu düzenle	Cached logon’lar	DC ve client event log’ları
Aynı AD öznitelikleri, SSSD ile Linux	Hayır	`ad_gpo_access_control` ile GPO logon hakları ya da `ad_access_filter`	Hayır: login anında değerlendirilir	Hayır	Grup veya GPO değişikliği, sonraki login’de görülür	Cached credentials, varsayılan olarak süresiz	syslog
`pam_time`	Hayır: host başına statik `time.conf`	Evet (yerel dosya)	Belgelenmemiş	Hayır	Her host’a dosya dağıt	Etkilenmez (yerel)	syslog
`pam_access`	Zaman boyutu yok	Evet (kullanıcı × kaynak)	Hayır	Hayır	Her host’a dosya dağıt	Etkilenmez (yerel)	syslog
cron veya systemd timer + kill	Ancak takvimi yeniden üreterek	Evet	Evet, sabit saatlerde	Mümkün, ama elle kurulur	Takvimi dağıt	Etkilenmez	Ne loglarsanız
Slurm + `pam_slurm_adopt`	Evet (job’lar)	Evet (node’lar)	Evet, sahiplenilen process’ler için job bitince	Desktop uyarısı yok	`scancel`, süre sınırı güncellemesi	`slurmctld` ve `slurmd`‘ye bağlı	`sacct`
PAM gate + watchdog + API (bu yazı)	Evet	Evet	Evet, bir poll aralığı içinde	Evet	Evet, single source of truth	Açık bir grace period, sonra fail-closed	Merkezi audit log

Windows Client’lar ve Group Policy:
LogonHoursPolicyDescription ayarı incelendiğinde; logon hours dolduğunda workstation’ı kilitleyebilmekte, bağlantıyı kesebilmekte veya oturumu kapatabilmektedir (logoff). Bir action tanımlandığında kullanıcı önceden uyarılır. Sıkça alıntılanan “Force logoff when logon hours expire” ayarı ise yalnızca SMB session’larını etkilemektedir. Makineler Windows çalıştırıyor ve takvim haftalık ve statik bir yapıda ise, yerleşik GPO mekanizması genellikle yeterlidir; ek kod yazmaya gerek kalmaz.

Linux ve SSSD Birlikteliği:
sssd-ad modülü, GPO logon haklarını (Interactive, RemoteInteractive vb.) değerlendirerek PAM servisleriyle eşleştirebilmekte; ad_access_filter ise login taleplerini LDAP filtresiyle kısıtlayabilmektedir. AD access provider ayrıca hesabın expire olup olmadığını denetler. Ancak bu kontrollerin tamamı PAM yığınının yalnızca login anında çalışan account aşamasında yürütülür. Ne sssd-ad ne de sssd-ldap man sayfası logonHours veya userWorkstations desteğinden bahseder. SSSD tarafında halihazırda çalışan bir session’ı sonlandıran hiçbir mekanizma bulunmamaktadır.

pam_time ve pam_access Modülleri:
pam_time yalnızca account aşamasını kapsar; görevi session sonlandırmak değil, erişim anında izin vermek veya reddetmektir. Kuralları her host’taki yerel /etc/security/time.conf dosyasında durur: “laboratuvar gece kapanır” gibi statik durumlar için yeterli olsa da, dinamik rezervasyonlar için kullanılamaz.

Slurm Yaklaşımı:
pam_slurm_adopt modülü, aktif bir job’ı bulunmayan node’lara SSH erişimini engelleyebilmekte ve SSH session’ını job’ın cgroup’una alarak job bitiminde temizlik yapabilmektedir. Ancak resmi belgelerde açıkça belirtildiği üzere, pam_systemd ile çakışmaktadır ve devre dışı bırakılmasını gerektirir. pam_systemd olmadan logind session’ı ve /run/user/$UID dizini oluşmayacağından, grafik desktop oturumlarının çalışması mümkün olmamaktadır. Dolayısıyla Slurm, desktop workstation’lar için uygun bir model sunmamaktadır.

Özetle; admission kontrolü çözülmüş bir problemdir. Ancak dinamik, makineye özel bir takvime göre merkezden yönetilen eviction, hazır araçlarla doğrudan karşılanamamaktadır.

Kurgulanan Mimari

Tasarım, birbirinin hata durumlarını tolere edecek biçimde yapılandırılmış beş ana bileşenden oluşmaktadır.

1. Single Source of Truth: Merkezi API

Merkezi servis; rezervasyonları, ban kayıtlarını, maintenance pencerelerini ve aktif session’ları barındırır. “Bu kullanıcı şu anda bu makinede bulunabilir mi?” sorusunun yanıtı daima server saati referans alınarak burada üretilir. Client’lar rezervasyon sürelerini asla yerel olarak hesaplamazlar. İptal, süre uzatma ve ban işlemleri tek merkezden yapılır; client tarafındaki saat kaymaları oturum süresini etkilemez ve her admission/eviction hareketi tek bir veritabanında audit log’u haline gelir.

Client’lar API üzerinde dört temel endpoint kullanır: check (login izni), validate (session geçerliliği ve kalan süre), heartbeat (host ve kullanıcının aktiflik bildirimi) ve end (session sonlandı bilgisi).

Her workstation’da, PAM yığınının account aşamasına pam_exec aracılığıyla hafif bir kontrol script’i yerleştirilmiştir:

# /etc/pam.d/common-account (Debian/Ubuntu), pam_sss'ten sonra
account required pam_exec.so quiet /usr/bin/python3 /opt/reservation/pam_gate.py

Auth aşaması kimlik doğrulamasını (SSSD üzerinden) gerçekleştirirken, account aşaması ilgili kullanıcının o makinede ve o anda yetkili olup olmadığını denetler. Bu aşama SSH public key login gibi auth adımının atlandığı senaryolarda da devreye girer. Test ortamında common-account yapılandırmasını kullanan tüm servisler (sshd, login, su, sudo, cron, atd, gdm-password ve systemd-user) gate’i tetiklemiştir.

Script, PAM_USER ortam değişkenini alarak API’yi sorgular ve 0 (izin) ya da 1 (ret) koduyla sonlanır. Yönetici hesapları ve UID değeri 1000’in altında kalan sistem hesapları bu denetimden muaf tutulur.

Gate’in Sınırı: Account aşaması yalnızca login anında bir defa çalıştırılır. Dolayısıyla tek başına süresi dolan kullanıcıları eviction sürecine sokamaz.

3. SSSD: Kimlik ve Offline Tuzağı

SSSD, Domain Controller (DC) üzerinden kimlik çözümleme ve auth süreçlerini yönetir. Bu mimaride iki parametre kritik öneme sahiptir:

[domain/example.local]
cache_credentials = True
offline_timeout = 15
offline_timeout_max = 60

cache_credentials, DC’ye ulaşılamadığında kullanıcının cached credentials ile login olabilmesini sağlar. Workstation’larda genelde istenen budur. Ancak cache’teki bilginin bayatlaması ciddi bir güvenlik tuzağıdır. Laboratuvar testlerinde, bir hesap bir kez login olduktan sonra AD üzerinde disable edilmiş, ardından DC erişilemez hale getirilmiştir. SSSD offline moda geçmiş ve cached parolayı kabul etmiştir. Rezervasyon geçerli göründüğü için PAM gate de kullanıcıyı içeri almıştır. sssd.conf man sayfasında offline_credentials_expiration varsayılan değeri 0 (No limit) olarak belgelenmiştir.

Aksi durumda ise SSSD offline iken yalnızca cache’teki kullanıcıları tanır; o gün açılmış yeni bir hesap PAM gate’e bile ulaşamadan reddedilir. offline_timeout_max değerini düşürmek (varsayılan 3600 sn yerine 60 sn) retry aralığının gereksiz uzamasını engeller.

4. Watchdog Servisi: Eviction

Her workstation’da çalışan bir systemd servisi, her 60 saniyede bir şu doğrulama döngüsünü işletir:

flowchart TD
    A[Her poll aralığında] --> B[logind session'ı olan kullanıcıları listele]
    B --> C{Admin ya da local hesap mı?}
    C -- evet --> B
    C -- hayır --> D[POST heartbeat]
    D --> E[GET validate]
    E -->|API erişilemez| F{Grace period aşıldı mı?}
    F -- hayır --> B
    F -- evet --> T
    E -->|geçerli, kalan > uyarı eşiği| B
    E -->|geçerli, kalan <= uyarı eşiği| W[Kullanıcıyı uyar] --> B
    E -->|geçersiz: süre bitti, iptal, maintenance| N[Notification gönder] --> T[Sonlandırmayı API'ye bildir, user processes temizle]

Watchdog servisi rezervasyon kurallarını yerel olarak yorumlamaz; tamamen merkezi API’den gelen yanıtlara göre eylem alır. Aktif kullanıcı listesi systemd-logind üzerinden çekilir; bu sayede pam_systemd tarafından kaydedilen tüm grafik, konsol ve SSH session’ları izlenebilir.

5. Heartbeat ve No-Show Yönetimi

Heartbeat çağrıları, server tarafında session’ın fiilen sürdüğünü teyit eder (heartbeat’i kesilen session kayıtları temizlenir), rezervasyonun “first login” zamanını damgalar ve eksikse session kaydını oluşturur. Bu mekanizma, API kesintisinde grace period üzerinden sisteme girmiş ve check endpoint’inden geçmemiş bir kullanıcının rezervasyonunun yanlışlıkla “no-show” sayılmasını engeller. First login damgası write-once niteliğindedir; logout, reboot ya da heartbeat timeout durumunda rezervasyon no-show’a dönüştürülmez.

sequenceDiagram
    participant U as Kullanıcı
    participant P as PAM yığını (sshd / gdm / login)
    participant S as SSSD
    participant G as pam_gate (account aşaması)
    participant A as Rezervasyon API
    U->>P: kimlik bilgileri (veya SSH key)
    P->>S: auth: DC üzerinden doğrula (offline ise cache)
    S-->>P: onay
    P->>S: account: AD access provider denetimi
    P->>G: account: PAM_USER, hostname
    G->>A: POST check {user, host}
    A-->>G: onay + rezervasyon bitişi, ya da ret + gerekçe
    alt API erişilemez durumda
        G->>G: local grace: aynı kullanıcı, cache süresi geçerli mi?
    end
    G-->>P: exit 0 / exit 1
    P-->>U: session açılır (pam_systemd logind kaydı üretir)

Tasarım Tercihleri ve Maliyetleri

Fail-Open mı Fail-Closed mı, ve Grace Period

Salt fail-closed bir yaklaşım, server restart veya deploy sırasında tüm kullanıcıları evict eder. Salt fail-open bir yaklaşım ise network kablosunu çekene sınırsız süre kazandırır. Bu yüzden sınırları belirlenmiş dengeli bir model tercih edilmiştir:

PAM Login Gate: API erişilemediğinde kural olarak fail-closed çalışır. İstisna olarak, yalnızca ilgili makinede son başarılı login olan kullanıcıya, o da grace period içinde kalmak kaydıyla izin verilir.
Watchdog Servisi: API erişimi koptuğunda session’ları hemen kapatmaz; belirlenen grace period boyunca (örneğin 10 dakika) tolerans tanır. Kesinti bu süreyi aşarsa session’lar güvenli biçimde sonlandırılır.

PAM ve Watchdog Görev Dağılımı

PAM gate olabildiğince yalın ve dumb tutulmuştur: tek bir HTTP request ve bir cache dosyası. PAM, sshd ve display manager içinde çalışır. Yavaşlayan veya çöken bir PAM modülü whitelist mantığı bozulursa yöneticiler dahil herkesi lockout edebilir. Bu nedenle gate tarafında sıkı timeout’lar uygulanmış ve network çağrısından önce yerel whitelist kontrolü yapılmıştır.

Interpreter overhead üzerine bir not: pam_exec ile her PAM çağrısında /usr/bin/python3 çalıştırmak, çağrı başına yaklaşık 30–80 ms process startup ve interpreter overhead getirir. Normal login frekansına sahip workstation’larda bu ek yük hissedilmez. Ancak yoğun PAM çağrısı alan ortamlarda (otomasyon cron job’ları, seri sudo kontrolleri veya dış kaynaklı SSH brute-force trafiği) sürekli Python process’i ayağa kaldırmak CPU üzerinde gereksiz spike’lar yaratabilir. Production ortamları için sertleştirme önerisi; bu script’i derlenmiş hafif bir binary’ye (Go, Rust veya C) ya da yerel bir Unix domain socket üzerinden persistent bir daemon ile haberleşen hafif bir client’a dönüştürmektir.

Zaman ya da muhakeme gerektiren her şey watchdog’dadır: warning’ler, bekleme, eviction kararı ve reporting.

SSH Kullanıcılarına Ulaşmayan Warning’ler (ve Wayland Tuzağı)

Watchdog servisi, süre dolumundan beş dakika önce kullanıcının masaüstüne notification iletmektedir. Ancak oturumun yalnızca SSH üzerinden yürütüldüğü durumlarda desktop notification’ların hedefine ulaşmadığı görülmüştür. Bu nedenle server tarafına, bitişe iki saat ve otuz dakika kala iletilen e-mail reminder’lar eklenmiştir.

Desktop notification’lar modern Linux ortamlarında bir diğer sessiz tuzağa sahiptir: Wayland. Root olarak DISPLAY=:0 varsayımıyla notify-send çalıştırmak legacy X11 ortamlarında sonuç verirken, per-session socket yapısına sahip Wayland altında (Ubuntu 22.04+ varsayılanı) sessizce fail olur. Root watchdog’un Wayland desktop session’ına bildirim basabilmesi için, kullanıcının /proc/<pid>/environ tablosundan DBUS_SESSION_BUS_ADDRESS değerini okuyup bildirimi kullanıcının D-Bus session bus’ı üzerinden dispatch etmesi gerekir.

Maintenance Modu ve Süre İadesi

Maintenance bir client özelliği değil, server-side bir state’tir. Maintenance modu aktifken check endpoint’i adminler hariç herkesi deny eder, validate ve heartbeat invalid yanıtı döner, no-show sweep durdurulur ve otomatik assignment durur. Heartbeat’teki bu davranış kritiktir: aksi takdirde heartbeat, maintenance’ın sildiği session kaydını recreate eder, validate geçerli der ve kimse evict edilemez.

Etkilenen rezervasyonlar maintenance süresi kadar uzatılır (makinedeki bir sonraki rezervasyonun başlangıç anına kadar). Bu uzatmanın sonraki rezervasyonları cascade (zincirleme) kaydırmaması tercih edilmiştir; zira bir telafi için sonraki kullanıcıların planını değiştirmek daha fazla karmaşıklığa yol açar. İade edilemeyen süreler admin’e raporlanır. Ayrıca maintenance pencereleri zorunlu bir planned end değerine sahiptir, böylece unutulan bakım pencereleri otomatik expire olur.

Admin Whitelist’i

Admin hesapları gate ve watchdog kontrollerini bypass eder. Her iki bileşen de network’e çıkmadan önce whitelist’i kontrol eder; böylece API bağlantısı kopmuş bir workstation’a admin her zaman girip onarım yapabilir.

Troubleshooting Sıralaması

Login sorunlarında kontroller upstream’den downstream’e doğru hiyerarşik bir sıraya bağlanmıştır: en upstream’deki kök neden önceliklendirilir. Örneğin kilitli bir AD hesabı loglarda password failure olarak da görünür; kilit durumu göz ardı edilip doğrudan password resetlenirse sorun çözülmez.

Test Edilen ve İyileştirilen Edge Case’ler

Kurgulanan yapının dayanıklılığını değerlendirmek amacıyla client bileşenleri bir test laboratuvarında yeniden oluşturulmuştur. Ortam; Samba tabanlı bir AD domain controller, SQLite üzerinde çalışan rezervasyon API’si ve systemd’nin PID 1 olduğu Ubuntu tabanlı bir workstation container’ından meydana getirilmiştir. Gerçekleştirilen testlerde karşılaşılan edge case’ler ve uygulanan sertleştirme adımları aşağıda özetlenmiştir.

1. `terminate-user` Çağrısı ve Süreçlerin Yaşam Döngüsü

Durum: Test ortamında doğrulandı. Önem: Yüksek.

Rezervasyon süresi dolduğunda watchdog tarafından çağrılan loginctl terminate-user komutu, kullanıcının systemd servis yöneticisini ve session process’lerini sonlandırmaktadır. Ancak iki tip sürecin çalışmaya devam edebildiği gözlemlenmiştir: kullanıcının önceden çıkış yaptığı ancak arkada bıraktığı background process’leri (logind üzerinde “closing” olarak görünenler) ile cron/at servisleri üzerinden başlatılan job’lar. Ubuntu varsayılanında KillUserProcesses=no olduğundan, logind session scope’u terk edilmiş (abandoned) sayılmakta ve process’ler yaşamaya devam etmektedir.

Sertleştirme:

İlk akla gelen refleks logind.conf içinde global KillUserProcesses=yes tanımlamak olabilir. Ancak kullanıcıların uzun süren simülasyon veya build işlerini tmux içinde yürüttüğü paylaşımlı workstation’larda bu kaba yaklaşım kaş yaparken göz çıkarır: anlık bir Wi-Fi kopması veya transient SSH drop durumunda, kullanıcının rezervasyonu sürerken aktif workload’u anında öldürülür.

Bu nedenle mimari, session drop ile reservation expiry durumlarını birbirinden ayrıştırır. Rezervasyon devam ettiği sürece geçici kopmalarda background job’ların yaşamasına izin verilir; yalnızca rezervasyon resmi olarak expire olduğunda watchdog kapsamlı cleanup adımını yürütür:

Verify (Doğrulama): terminate-user çağrısının ardından watchdog, ilgili UID’ye ait çalışan process kalıp kalmadığını kontrol eder (pgrep -u <UID>).
User Slice Teardown: Process’ler devam ediyorsa doğrudan kullanıcının cgroup slice’ı durdurulur (systemctl stop user-<UID>.slice); böylece “closing” durumunda asılı kalan tüm session scope’ları ve alt süreçler force clean edilir.
Escalation ve Alarm: Kapanmayan dirençli process’ler bulunursa loginctl kill-user --signal=SIGKILL devreye sokulur ve durum merkezi API’ye alert olarak bildirilir.
GPU Context ve /dev/shm Temizliği: Yüksek kaynaklı GPU/CUDA makinelerinde CPU süreçlerinin durdurulması her zaman yeterli olmayabilir; çöken veya zombi kalan CUDA context’leri ile /dev/shm altında bırakılan paylaşımlı bellek (shared memory) segmentleri sonraki kullanıcının GPU allocation’ını kilitleyebilir. Bu nedenle slice durdurulduktan sonra /dev/shm üzerindeki kullanıcı kalıntıları temizlenir ve gerekirse GPU aygıt düğümleri (fuser -v /dev/nvidia* veya nvidia-smi) denetlenir.
Out-of-band Execution Control: cron ve at araçları yalnızca admin’lere sınırlandırılır (cron.allow, at.allow); watchdog ise yalnızca logind session listesine değil, doğrudan process table’a (ps -eo uid) bakar.

2. Client ve Server Arasındaki Karşılıklı Güven Doğrulaması

Durum: Doğrulandı. Önem: Yüksek.

Client ile API arasındaki iletişimin şifrelenmemiş HTTP üzerinden yapıldığı ve session endpoint’lerinin kimlik doğrulaması aramadığı ilk senaryoda; client’ın sunduğu hostname beyanına doğrudan güvenildiği tespit edilmiştir. Laboratuvar ortamında ws01 makinesinin ws02 adına sorgu yaparak geçerli rezervasyon için onay alabildiği ve oturum açtırabildiği doğrulanmıştır.

Sertleştirme: Client’ta sabitlenmiş CA sertifikasıyla HTTPS zorunlu kılınmış, düz metin http:// yapılandırmaları reddedilmiştir. Makine kimliğinin teyidi için domain’e dahil her workstation’da bulunan /etc/krb5.keytab dosyasındaki host/<fqdn> principal’ı kullanılmıştır. Client’ın API’ye Kerberos (SPNEGO) ile bağlanması, server’ın da makine adını request body’den değil doğrulanmış ticket üzerinden türetmesi sağlanmıştır (alternatif olarak per-machine mTLS mimarisi geçerlidir).