User, Group ve Permission'lar: rwx, chmod, chown, umask, sudo ve Service Kullanıcıları

Sürüm notu: Bu yazıdaki komutlar Ubuntu Server 24.04.5 LTS (kernel 6.8, sudo 1.9.15p5, coreutils 9.4, acl 2.3.2) çalıştıran bir test VM'inde, ASP.NET Core 10.0.15 runtime'ıyla denenmiştir.

Önce Tahmin Et

Ev klasöründe catalog adında bir klasör ve içinde books.txt var. Klasörün izinlerini iki kez değiştiriyorsun; dosyanın kendi izinleri hiç değişmiyor (-rw-rw-r--):

$ chmod 600 ~/catalog; ls -ld ~/catalog
drw------- 2 ada ada 4096 Nov 14 14:40 /home/ada/catalog
$ chmod 300 ~/catalog; ls -ld ~/catalog
d-wx------ 2 ada ada 4096 Nov 14 14:40 /home/ada/catalog

Her iki durumda ls ~/catalog ve cat ~/catalog/books.txt çalışır mı? Klasörün sahibi sensin ve ilk durumda okuma iznin de var. Sezgin "600'de ikisi de çalışır, 300'de ikisi de çalışmaz" diyorsa yazının ilk bölümü tam sana göre.

İkinci yazıda Bookstore'un (sitedeki serilerin ortak örnek uygulaması, bir online kitapçı) dosyalarını yerleştirdik ama uygulamayı kendi kullanıcımızla çalıştırdık. Bu yazıda Linux permission modelini, uygulama için ayrı bir service kullanıcısını, deploy kullanıcısını ondan ayırmayı, secret dosyalarını ve sudo'yu anlatıyoruz.

rwx: Dosyada ve Dizinde Ayrı Anlamlar

Her dosyanın bir sahibi (user), bir grubu (group) ve üç izin kümesi var: sahip, grup ve diğer herkes (others). Her kümede üç bit: r (okuma), w (yazma), x (çalıştırma). Linux bir erişimde yalnızca tek bir kümeye bakar: sahibi sen isen sahip kümesine, değilsen ve gruptaysan grup kümesine, ikisi de değilse others kümesine. Root bu kontrollerin çoğunu atlar.

Dosyada anlamlar sezgiseldir: r içeriği okumak, w içeriği değiştirmek, x program olarak çalıştırmak. Dizinde ise farklıdır, tahminin cevabı da burada:

$ chmod 600 ~/catalog
$ ls ~/catalog
books.txt
$ cat ~/catalog/books.txt
cat: /home/ada/catalog/books.txt: Permission denied
$ chmod 300 ~/catalog
$ ls ~/catalog
ls: cannot open directory '/home/ada/catalog': Permission denied
$ cat ~/catalog/books.txt
Dune

Dizinde r, içindeki isimleri listelemek demek. x ise dizinin içine girmek ve içindeki bir isme ulaşmak demek; bir dosyayı açmak için yolun üstündeki her dizinde x gerekir. 600'de isimleri görebildik ama hiçbir dosyaya ulaşamadık; 300'de listeleyemedik ama adını bildiğimiz dosyayı okuduk. Dizinde w ise içinde dosya oluşturmak, silmek ve adını değiştirmek demek; yani bir dosyayı silmek için dosyanın değil, bulunduğu dizinin iznine bakılır. "Permission denied" aldığında yalnızca dosyaya değil, path'teki her dizine bakmanın sebebi bu.

chmod, chown ve umask

chmod iki biçimde yazılır. Octal biçimde her küme bir rakam: r=4, w=2, x=1 toplanır; 640, sahip için 6 (rw), grup için 4 (r), others için 0 demek. Sembolik biçimde kimi (u, g, o, a) ve ne yapılacağını (+, -, =) yazarsın:

$ chmod 640 report.csv; ls -l report.csv
-rw-r----- 1 ada ada 0 Nov 14 14:40 report.csv
$ chmod u+x,g-r,o= report.csv; ls -l report.csv
-rwx------ 1 ada ada 0 Nov 14 14:40 report.csv
$ stat -c "%a %A %n" report.csv
700 -rwx------ report.csv

Octal biçim "tam olarak bu olsun" demek için, sembolik biçim "şunu ekle ya da çıkar, gerisine dokunma" demek için uygun. stat -c "%a" bir dosyanın iznini octal olarak verir; script'lerde ve dokümantasyonda iki biçimi eşleştirirken işe yarar. Sahibi ve grubu chown user:group dosya değiştirir, klasörün tamamı için -R ekle; sahipliği yalnızca root değiştirebilir.

Yeni oluşturulan dosyanın izni umask ile belirlenir: dosyalar 666'dan, dizinler 777'den başlar ve umask'taki bitler çıkarılır.

$ umask
0002
$ touch report.csv; mkdir exports; ls -ld report.csv exports
drwxrwxr-x 2 ada ada 4096 Nov 14 14:40 exports
-rw-rw-r-- 1 ada ada    0 Nov 14 14:40 report.csv
$ sudo bash -c "umask; touch /tmp/root-file; ls -l /tmp/root-file"
0022
-rw-r--r-- 1 root root 0 Nov 14 14:40 /tmp/root-file
$ grep -E "^(UMASK|USERGROUPS_ENAB)" /etc/login.defs
UMASK		022
USERGROUPS_ENAB yes

Ubuntu'da varsayılan umask 022, ama USERGROUPS_ENAB yes olduğu için kendi adıyla aynı adlı özel bir grubu olan normal kullanıcılarda grup yazma biti açık kalıyor (0002). Grubunda yalnızca kendisi olduğu için bu güvenli; ama ortak bir gruba ait dizinlerde çalışırken, birazdan göreceğimiz gibi, dosyaların grup tarafından yazılabilir oluşması demek.

Bookstore İçin Service Kullanıcısı

Bir web uygulamasını root olarak çalıştırmak, uygulamadaki her açığı tüm sunucunun açığına çevirir. Kendi kullanıcınla çalıştırmak da iyi değil: uygulama senin SSH (uzak bağlantı protokolü) key'lerine, ev klasörüne ve sudo yetkine yakın durur. Doğrusu, yalnızca uygulama için açılmış, giriş yapamayan bir system kullanıcısı:

$ sudo useradd --system --no-create-home --shell /usr/sbin/nologin bookstore
$ id bookstore
uid=999(bookstore) gid=988(bookstore) groups=988(bookstore)
$ getent passwd bookstore
bookstore:x:999:988::/home/bookstore:/usr/sbin/nologin
$ sudo su - bookstore
su: warning: cannot change directory to /home/bookstore: No such file or directory
This account is currently not available.
$ sudo -u bookstore whoami
bookstore

--system 1000'in altında bir UID (kullanıcı kimlik numarası) seçer; şifre verilmediği için hesabın şifresi kilitli kalır (/etc/shadow'da !); /usr/sbin/nologin shell'i bu kullanıcıyla etkileşimli oturum açılmasını engeller. useradd kayda bir ev klasörü yolu yazdı ama --no-create-home yüzünden klasör yok; uyarı bundan. Buna rağmen sudo -u bookstore ile bu kullanıcı adına tek bir komut çalıştırabiliyoruz, çünkü sudo komutu shell üzerinden değil doğrudan başlatıyor. systemd service'i de aynı şekilde User=bookstore ile başlatacak (beşinci yazı).

Deploy Kullanıcısı, Ortak Grup ve setgid

Uygulamayı çalıştıran kullanıcı ile yeni release'i sunucuya koyan kullanıcı aynı olmamalı. Uygulama kendi koduna yazabiliyorsa, uygulamadaki bir açık kodun kendisini değiştirebilir. Bu yüzden dört klasörü şöyle ayarlıyoruz: release'leri deploy kullanıcısı yazar, bookstore grubu okur; durum ve log klasörlerine yalnızca bookstore yazar; configuration'ı root yazar, bookstore grubu okur.

$ sudo useradd --create-home --shell /bin/bash deploy
$ sudo chown -R deploy:bookstore /opt/bookstore
$ sudo chmod 2755 /opt/bookstore/releases
$ sudo chown bookstore:bookstore /var/lib/bookstore /var/log/bookstore
$ sudo chmod 750 /var/lib/bookstore /var/log/bookstore
$ sudo chown root:bookstore /etc/bookstore && sudo chmod 750 /etc/bookstore
$ ls -ld /opt/bookstore/releases /etc/bookstore /var/lib/bookstore /var/log/bookstore
drwxr-x--- 2 root      bookstore 4096 Nov 14 14:44 /etc/bookstore
drwxr-sr-x 4 deploy    bookstore 4096 Nov 14 14:41 /opt/bookstore/releases
drwxr-x--- 2 bookstore bookstore 4096 Nov 14 14:42 /var/lib/bookstore
drwxr-x--- 2 bookstore bookstore 4096 Nov 14 14:30 /var/log/bookstore

2755'teki baştaki 2, setgid biti; ls'te grup kümesindeki s olarak görünüyor. Dizinde setgid, içinde oluşturulan her şeyin grubunun, oluşturan kişinin grubu yerine dizinin grubu olmasını sağlar. Farkı iki release klasörüyle gördüm:

$ sudo -u deploy mkdir /opt/bookstore/releases/2026-11-14-3
$ ls -ld /opt/bookstore/releases/2026-11-14-3
drwxrwsr-x 2 deploy bookstore 4096 Nov 14 14:44 /opt/bookstore/releases/2026-11-14-3
$ sudo chmod g-s /opt/bookstore/releases
$ sudo -u deploy mkdir /opt/bookstore/releases/2026-11-14-4
$ ls -ld /opt/bookstore/releases/2026-11-14-4
drwxrwxr-x 2 deploy deploy 4096 Nov 14 14:44 /opt/bookstore/releases/2026-11-14-4

setgid açıkken yeni release bookstore grubuyla geldi ve uygulama onu okuyabilir; kapatınca deploy grubuyla geldi ve uygulama için others kümesine düştü. İzinlerde iki detay daha var. Birincisi, deploy'un umask'ı 0002 olduğu için yeni dosyalar -rw-rw-r-- ile, yani grup tarafından yazılabilir oluşuyor; bu da uygulamanın kendi Bookstore.Api.dll'ine yazabilmesi demek. Burada rsync'e dikkat: rsync -a izinleri ve grubu kaynaktan kopyaladığı için yeni release klasöründe setgid bitini düşürdü ve dosyalar deploy grubuyla geldi; deploy bookstore grubunda olmadığı için bunu --chmod ile de geri koyamadı. İzinleri ve grubu kopyalamayan rsync -rlt'yi deploy için umask 022 ile çalıştırınca klasör drwxr-sr-x, dosyalar bookstore grubuyla ve 644 (programın kendisi 755) geldi. İkincisi, ilk denememde deploy'u bookstore grubuna eklemiştim ve aşağıdaki secret dosyasını da okuyabildiğini gördüm. Grup üyeliği, o grubun okuyabildiği her şeyi okumak demek; deploy klasörün sahibi olduğu için gruba ihtiyacı yok, sudo gpasswd -d deploy bookstore ile çıkardım.

Secret dosyası için aynı mantık: sahibi root, grubu bookstore, izni 640. sudo tee ile oluşan dosya root'un umask'ı 022 yüzünden önce 644 geldi, yani herkes okuyabiliyordu; hemen düzelttim.

$ echo "ConnectionStrings__Default=Server=127.0.0.1;Database=BookstoreDb;User Id=bookstore_app;Password=<secret>" | sudo tee /etc/bookstore/secrets.env > /dev/null
$ sudo ls -l /etc/bookstore/secrets.env
-rw-r--r-- 1 root root 105 Nov 14 14:44 /etc/bookstore/secrets.env
$ sudo chown root:bookstore /etc/bookstore/secrets.env && sudo chmod 640 /etc/bookstore/secrets.env
$ sudo ls -l /etc/bookstore/secrets.env
-rw-r----- 1 root bookstore 105 Nov 14 14:44 /etc/bookstore/secrets.env
$ sudo -u bookstore cat /etc/bookstore/secrets.env
ConnectionStrings__Default=Server=127.0.0.1;Database=BookstoreDb;User Id=bookstore_app;Password=<secret>
$ sudo -u deploy cat /etc/bookstore/secrets.env
cat: /etc/bookstore/secrets.env: Permission denied
$ cat /etc/bookstore/secrets.env
cat: /etc/bookstore/secrets.env: Permission denied

sudo tee kalıbına dikkat: sudo echo ... > /etc/... çalışmaz, çünkü yönlendirmeyi sudo değil senin shell'in, senin yetkinle yapar. Uygulamayı service kullanıcısıyla çalıştırınca sonuç beklediğimiz gibi oldu:

$ ps -o user,pid,cmd -C dotnet
USER         PID CMD
booksto+    2269 dotnet Bookstore.Api.dll --urls http://127.0.0.1:5000
$ sudo -u bookstore touch /opt/bookstore/current/hacked.txt
touch: cannot touch '/opt/bookstore/current/hacked.txt': Permission denied
$ sudo -u bookstore touch /var/lib/bookstore/state.txt && sudo ls -l /var/lib/bookstore
total 0
-rw-rw-r-- 1 bookstore bookstore 0 Nov 14 14:42 state.txt
$ sudo -u bookstore cat /home/ada/.ssh/authorized_keys
cat: /home/ada/.ssh/authorized_keys: Permission denied

Uygulama kendi koduna yazamıyor, durum klasörüne yazabiliyor ve senin ev klasörüne (drwxr-x---) giremiyor. ps sekiz karakterden uzun kullanıcı adlarını booksto+ diye kısaltıyor; tam adı için ps -o user:20.

Sticky Bit ve ACL

/tmp herkesin yazabildiği bir dizin; o hâlde herkes başkasının dosyasını da silebilir mi? Hayır, çünkü üzerinde sticky bit var:

$ ls -ld /tmp
drwxrwxrwt 12 root root 4096 Nov 14 14:41 /tmp
$ sudo -u deploy rm /tmp/ada-notes.txt
rm: cannot remove '/tmp/ada-notes.txt': Operation not permitted

Sondaki t, dizine yazabilen herkesin içinde dosya oluşturabileceğini ama yalnızca kendi dosyasını silip adını değiştirebileceğini söylüyor. Aynı denemede deploy, izni 666 olan bu dosyaya yazamadı da; Ubuntu'nun fs.protected_regular = 2 kernel ayarı sticky dizinlerde başkasına ait dosyaların bu şekilde açılmasını engelliyor.

Sahip, grup ve others üçlüsü bazen yetmez: "bu dosyayı bir kişi daha okusun ama gruba girmesin" gibi. ACL (Access Control List; dosyaya kullanıcı ya da grup bazında ek izin satırları ekleyen mekanizma) bunun için. setfacl ve getfacl cloud image'da yoktu, sudo apt install acl ile kurdum:

$ sudo setfacl -m u:ada:r /etc/bookstore/secrets.env
$ sudo getfacl /etc/bookstore/secrets.env
getfacl: Removing leading '/' from absolute path names
# file: etc/bookstore/secrets.env
# owner: root
# group: bookstore
user::rw-
user:ada:r--
group::r--
mask::r--
other::---

$ sudo ls -l /etc/bookstore/secrets.env
-rw-r-----+ 1 root bookstore 105 Nov 14 14:40 /etc/bookstore/secrets.env
$ sudo setfacl -b /etc/bookstore/secrets.env

ls çıktısındaki +, dosyada ACL olduğunu söyleyen tek işaret; izinleri yalnızca ls -l ile okuyan biri bu ek satırı görmez. Bu yüzden ACL'i istisna için kullan, düzen kurmak için grupları. setfacl -b bütün ek satırları siler.

sudo, sudoers ve visudo

sudo bir komutu başka bir kullanıcı adına, varsayılan olarak root adına çalıştırır ve kimin neyi çalıştırabileceğini /etc/sudoers ile /etc/sudoers.d/ belirler. sudo -l sana ne izin verildiğini gösterir:

$ sudo -l
Matching Defaults entries for ada on bookstore-dev:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User ada may run the following commands on bookstore-dev:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL
$ sudo cat /etc/sudoers.d/90-cloud-init-users
# Created by cloud-init v. 26.1-0ubuntu1~24.04.1 on Sat, 14 Nov 2026 14:04:52 +0000

# User rules for ada
ada ALL=(ALL) NOPASSWD:ALL

İlk satır sudo grubundan geliyor (/etc/sudoers'taki %sudo ALL=(ALL:ALL) ALL), ikincisi cloud-init'in eklediği dosyadan. Cloud image'lardaki varsayılan kullanıcı şifresiz sudo ile gelir; bu VM'de de öyle. secure_path ise sudo ile çalışan komutların hangi PATH (komutların arandığı klasör listesi) ile arandığı; /usr/local/bin içinde olmasa sudo mytool "command not found" derdi.

deploy kullanıcısının yalnızca Bookstore service'ini yeniden başlatabilmesini istiyoruz, root olmasını değil. sudoers dosyasını asla doğrudan bir editörle değiştirme: bir yazım hatası sudo'yu tamamen kullanılamaz hâle getirir ve root şifresi olmayan Ubuntu'da geri dönmek için konsola ihtiyaç duyarsın. visudo dosyayı kaydetmeden önce kontrol eder; drop-in dosyalar için sudo visudo -f /etc/sudoers.d/bookstore-deploy kullanılır. Ben dosyayı önce geçici bir yerde yazıp -c ile kontrol ettim:

$ cat /tmp/bookstore-deploy
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart bookstore-api, /usr/bin/systemctl status bookstore-api
$ sudo visudo -cf /tmp/bookstore-deploy
/tmp/bookstore-deploy: parsed OK
$ sudo visudo -cf /tmp/bad
/tmp/bad:1:68: syntax error
deploy ALL=(root) NOPASSWD /usr/bin/systemctl restart bookstore-api
                                                                   ^
$ sudo install -m 440 -o root -g root /tmp/bookstore-deploy /etc/sudoers.d/bookstore-deploy
$ sudo -u deploy sudo -l
...
User deploy may run the following commands on bookstore-dev:
    (root) NOPASSWD: /usr/bin/systemctl restart bookstore-api, /usr/bin/systemctl status bookstore-api
$ sudo -u deploy sudo -n /usr/bin/systemctl status bookstore-api
Unit bookstore-api.service could not be found.
$ sudo -u deploy sudo -n cat /etc/bookstore/secrets.env
sudo: a password is required

Hatalı dosyada yalnızca NOPASSWD'den sonraki iki nokta eksik ve visudo onu yakaladı. İzin verilen komut çalıştı (service'i henüz kurmadık, onu beşinci yazıda yapacağız); izin verilmeyen komut için sudo şifre istedi, deploy'un şifresi olmadığı için de bu bir red. Komutları tam path'leriyle ve argümanlarıyla yazmak önemli: /usr/bin/systemctl tek başına yazılsaydı deploy her service'i durdurabilir, hatta systemctl edit ile root olarak bir editör açabilirdi. Drop-in dosyasının adında nokta olmamalı; @includedir adında nokta olan ya da ~ ile biten dosyaları atlar. Kuralı sunucuda elle yazıp unutmamak için repoda deploy/linux/sudoers.d/bookstore-deploy olarak tutuyoruz.

su ile sudo'nun farkı kimin şifresinin sorulduğunda. su - hedef kullanıcının, yani root'un şifresini ister; Ubuntu'da root hesabı kilitli geldiği için bu çalışmaz:

$ su - -c whoami < /dev/null
Password: su: Authentication failure
$ sudo passwd -S root
root L 2026-10-17 0 99999 7 -1
$ sudo -i whoami
root

L kilitli demek. Root shell'e ihtiyacın varsa sudo -i (root'un login shell'i) ya da sudo -s; ama tek bir komut için sudo komut hem daha az risk hem log'da daha net bir iz. Ubuntu 26.04'te sudo komutunun arkasında artık Rust ile yazılmış sudo-rs var ve eski sudo deposunda kalmaya devam ediyor; sudoers dosyaları çoğu durumda aynı şekilde çalışıyor. Farkları serinin son yazısında topluyoruz.

Üretimde Dikkat

Her uygulamaya kendi service kullanıcısı. Aynı sunucuda Bookstore.Api ile bir arka plan worker'ı ya da başka bir uygulama çalışıyorsa hepsini aynı kullanıcıyla çalıştırma; birindeki açık diğerinin secret'larını açmasın. Bu yazıdaki izinleri systemd tarafında ProtectSystem=strict ve ReadWritePaths=/var/lib/bookstore gibi ayarlar destekler; ikisi birbirinin yerine geçmez, katman olarak eklenir. Unit dosyasının hardening tarafı Web Server'lar ve Hosting serisinin systemd yazısında.

sudo kayıtlarını oku. Her sudo çağrısı /var/log/auth.log'a ve journal'a yazılır: kim, hangi klasörde, hangi komutu çalıştırdı. "Production'da kim ne yaptı" sorusunun ilk cevabı oradadır; log okumayı altıncı yazıda ele alıyoruz. Kişisel hesaplarla girip sudo kullanmak, ortak bir root oturumuna göre bu yüzden de daha iyi.

Sık Düşülen Tuzaklar

"Permission denied"ı chmod 777 ile çözmek. Sorunu gizler, açığı büyütür: dosyayı sunucudaki her kullanıcı ve her process değiştirebilir hâle gelir. Önce kimin erişmeye çalıştığını (ps -o user), sonra path'teki her dizinin iznini kontrol et; namei -l /etc/bookstore/secrets.env yolu adım adım izinleriyle listeler ve ada olarak çalıştırınca hangi dizinde takıldığını (drwxr-x--- root bookstore bookstore) doğrudan gösterdi ve doğru kullanıcıya ya da gruba en az gereken izni ver.

sudo ile oluşturulan dosyaların root'a ait kalması. Kendi ev klasöründe bir şeyi alışkanlıkla sudo ile kopyalarsan sonraki adımda sen yazamazsın:

$ sudo cp -r ~/bookstore-api ~/staging
$ ls -ld ~/staging
drwxr-xr-x 2 root root 4096 Nov 14 14:42 /home/ada/staging
$ cp ~/bookstore-api/Bookstore.Api.dll ~/staging/
cp: cannot create regular file '/home/ada/staging/Bookstore.Api.dll': Permission denied
$ sudo chown -R ada:ada ~/staging

Aynı şey sudo dotnet publish, sudo npm install ve sudo git pull'da da olur: bin/, obj/, node_modules ya da .git içindeki dosyalar root'un olur ve bir sonraki normal çalıştırma hata verir. sudo'yu yalnızca gerçekten root gereken adımda kullan.

Secret dosyasını 644 bırakmak. sudo tee ya da bir editörle oluşturulan dosya umask 022 ile 644 gelir ve sunucudaki herkes connection string'i okur. Secret dosyasını oluşturduğun komutun hemen arkasından chown root:bookstore ve chmod 640 gelmeli; ya da en baştan sudo install -m 640 -o root -g bookstore /dev/null /etc/bookstore/secrets.env ile boş ve doğru izinli dosya oluşturup sonra içini doldur.

Grup üyeliğinin anında geçerli olacağını sanmak. usermod -aG ya da gpasswd -a ile bir kullanıcıyı gruba eklediğinde, o kullanıcının açık oturumları eski grup listesiyle devam eder; değişiklik yeni bir oturumda (SSH'tan çıkıp tekrar girince) ya da service'in restart'ında geçerli olur. Bir de usermod -G'yi -a'sız çalıştırmak kullanıcıyı listede olmayan bütün gruplardan, sudo dahil, çıkarır.

Küçük Bir Deneme

★☆☆ Kendi VM'inde bir klasör oluştur ve izinlerini sırayla 700, 600, 300 ve 100 yap. Her birinde ls, cat, touch ve rm ile içindeki bir dosyaya ne yapabildiğini bir tabloya yaz.

★★☆ bookstore service kullanıcısını ve deploy kullanıcısını oluştur, dört klasörü bu yazıdaki gibi ayarla ve Bookstore.Api'yi sudo -u bookstore ile çalıştır. Uygulamanın /var/lib/bookstore'a yazabildiğini, release klasörüne yazamadığını ve deploy'un secret dosyasını okuyamadığını kendin doğrula.

★★★ /etc/sudoers.d/bookstore-deploy'u visudo -f ile oluştur ve deploy'a yalnızca systemctl restart bookstore-api izni ver. Sonra kuralı bilerek gevşet (/usr/bin/systemctl yaz, argümansız) ve deploy ile sudo systemctl edit bookstore-api çalıştırınca ne olduğunu gör. Bu senaryo neden kuralların argümanlarıyla yazılması gerektiğini gösteriyor.

Uygulama artık doğru kullanıcıyla çalışıyor ama hâlâ elle başlatıp elle durduruyoruz. Bir sonraki yazıda process'lere bakıyoruz: ps ve top çıktısını okumak, signal'lerle .NET uygulamasını düzgün kapatmak, SSH kopunca neden process'in öldüğü ve zombie'ler.