Linux Kullanıcıları, Grupları ve İzinleri: Pratik Bir Onboarding İş Akışı

Pazartesi Sabahı Erişim İsteği

Pazartesi sabahı, yeni bir takım üyesi projenize katılıyor ve bugün Ubuntu VPS’nizdeki paylaşılan geliştirme çalışma alanına erişim gerekiyor. Giriş yapabilmeli, takım dizinini açabilmeli ve başka birinin her küçük görev için yardımını beklemeden normal çalışmalar yapabilmelidir. Root erişimi almamalıdır. Ayrıca kısıtlı release-secret alanından uzak durmalıdır.

Linux kullanıcıları, grupları ve izinleri üç ayrı ders konusu gibi hissetmeyi bırakıp pratik bir sistem olarak hareket etmeye başladığı yer burası. Sunucu AlexHost VPS’de yaşasın, başka bir yerde yaşasın, erişim sorusu her yerde aynıdır: tam kontrol vermeden nasıl yararlı erişim sağlarsınız?

Bu kılavuz, bu tek onboarding isteğini başından sonuna kadar takip eder, böylece her komutun açık bir işi ve hikayedeki yeri vardır. Kullanıcı, grup ve izin gibi terimler kendi başlarına hiç net hissettiğiniz olmadıysa, bunları bir araya getirmenin en kolay yolu budur.

Workflow:
user account → group membership → ownership alignment → permissions → verification

Herhangi Bir Komuttan Önce Bir Mental Model

Herhangi bir komuttan önce, aklınızda bir analoji tutun: sunucuyu bir ofis binası gibi düşünün. Bir kullanıcı, bir kişinin adlandırılmış rozeti. Bir grup, ait oldukları departman. İzinler, odalar ve dolaplar üzerindeki kapı kuralları. Linux erişimi, izole komutları ezberlemeye çalışmak yerine bu şekilde okuduğunuzda çok daha kolay hale gelir.

Üç temel soru basittir:

• Bir kullanıcı şu soruyu yanıtlar: “Bu kimdir?”
• Bir grup şu soruyu yanıtlar: “Hangi paylaşılan takımın parçasıdır?”
• İzinler şu soruyu yanıtlar: “Burada ne yapabilir?”

Bu aynı zamanda en az ayrıcalık ilkesinin de kalbidir: birine işi yapmak için tam olarak yeterli erişim verin ve daha fazlasını vermeyin. Yalnız izinler hiçbir zaman tüm sorunu çözmez, çünkü yanlış kimlik veya yanlış takım üzerindeki doğru kural yine de yanlış sonuç üretir.

Aynı mantık her dosya ve dizinde görünür. Linux önce siz sahibi olup olmadığınızı, yolun grubuna uyup uymadığınızı veya diğerleri — yani makinedeki diğer herkes — kategorisine girip girmediğinizi kontrol eder. Ancak bundan sonra ilgili kuralı uygular. Bu nedenle aynı yol farklı kullanıcılar için farklı davranabilir.

Aşağıdaki kompakt çeviri tablosu bu makalenin geri kalanı için yeterlidir:

📝 Not: Aşağıdaki komutlar Ubuntu dostu örnekler kullanır, ancak mental model kendisi Linux genelinde geçerlidir.

Buradan itibaren, ilk adım açık hale gelir: Maya takımla herhangi bir şey paylaşabilmeden önce, sistem onu kendi kişi olarak bilmesi gerekir.

Adım 1: Sisteme Kişiyi Ekleyin

Bir Linux kullanıcı hesabı sadece bir listenin etiketi değildir. Maya’ya bir giriş kimliği, bir ev dizini ve sunucudaki diğer herkesin ayrı bir çalışma bağlamı verir. Bu ayrım, sorumluluk sahibi olmayı mümkün kılar. Bir şey değişirse, kim değiştirdiğini söyleyebilirsiniz. Erişimin dar kalması gerekiyorsa, bunu paylaşılan gizemli bir giriş yerine tek bir gerçek hesaba sınırlayabilirsiniz.

Ubuntu’da, insan dostu hesap oluşturma yöntemi şu şekildedir:

sudo adduser maya

Ubuntu sizi normal kurulum sürecinde yönlendirecek ve genellikle /home/maya‘yı aynı anda oluşturacaktır. Ayrıca useradd‘i betiklerde veya düşük seviye belgelerde görebilirsiniz. Debian/Ubuntu sistemlerinde, adduser normal bir insan hesabı için genellikle daha dostça bir seçimdir.

Bu, paylaşılan hesapların neden kötü bir alışkanlık olduğunun nedenidir. Birden fazla kişi aynı kullanıcı olarak giriş yaparsa — ya da daha kötüsü, “sadece root kullan” — hemen izlenebilirliği kaybedersiniz ve daha sonraki her izin kararı daha gevşek hale gelir. Bir kullanıcı hesabı Maya’nın kim olduğunu cevaplar. Henüz onun hangi paylaşılan proje alanını kullanabileceğini cevaplamaz.

Adım 2: Onları Doğru Takıma Koyun

Artık Maya var, ancak yine de paylaşılan çalışma alanıyla hiçbir ilişkisi yok. İşte burada gruplar kullanışlı hale geliyor. Birincil grup varsayılan olarak hesabı takip eder. Ek gruplar, paylaşılan erişimin birden fazla kişi ve birden fazla proje arasında temiz bir şekilde ölçeklenebilmesi için bir kullanıcıya eklediğiniz ekstra takımlardır.

Proje grubunuz zaten mevcut değilse, önce oluşturun. Ardından Maya’nın mevcut ek üyeliklerini değiştirmek yerine onu bu gruba ekleyin.

⚠️ Uyarı: usermod -G devteam maya komutunu -a olmadan kullanmak Maya’nın mevcut ek gruplarını değiştirebilir. -a bayrağı “ekle” anlamına gelir ve bu kısmın güvenli olmasını sağlar.

Grubu oluşturmak ve Maya’nın bunun parçası olduğunu doğrulamak için aşağıdaki komutları kullanın:

sudo groupadd devteam
sudo usermod -aG devteam maya
id maya

devteam zaten varsa, groupadd satırını atlayın. id çıktısında, devteam öğesinin Maya’nın grupları arasında listelendiğini görmek istiyorsunuz:

Bu çıktı, takım üyeliğinin orada olduğunu kanıtlar. Dizinin kendisi takımı yok sayan bir şekilde sahip olunup gruplandırılmışsa, Maya’nın çalışma alanını kullanabileceğini henüz kanıtlamaz.

Adım 3: Sahipliği Çalışma Alanıyla Eşleştirin

Bu, birçok başlangıç seviyesi kullanıcının hayal kırıklığının arkasındaki eksik halka. Sonraki soru çalışma alanının kendisi hakkında: kim sahibi ve hangi grup buna bağlı? Bu hizalanana kadar, Maya’nın doğru takım üyeliğinin uygulanacak yararlı bir yeri yoktur.

Bu kılavuz için bir paylaşılan yol ve bir kısıtlı yol kullanın. Paylaşılan takım alanı /srv/devworkspace olacak. Özel alan /srv/release-secrets olacak ve içinde bir örnek dosya olacak. Her iki yolu da önce oluşturun:

sudo mkdir -p /srv/devworkspace /srv/release-secrets
sudo touch /srv/release-secrets/deploy-key.txt

Ardından, bu yolların şu anda nasıl göründüğünü inceleyin:

ls -ld /srv/devworkspace /srv/release-secrets
ls -l /srv/release-secrets/deploy-key.txt

-d burada önemlidir çünkü ls‘ye dizinin içeriğini listelemek yerine dizinin kendisini tanımlamasını söyler. Uzun listede üç parçayla başlayın. Önce soldaki izin dizesine bakın. Ardından sahibi ve grubu kontrol edin. Her iki yol hala root root gösteriyorsa, Maya’nın yeni devteam üyeliğinin henüz bağlanacak yararlı bir şeyi yoktur.

Yalnızca grubu değiştirmeniz gerekiyorsa, chgrp devteam /srv/devworkspace bunu yapardı. Burada, chown owner:group daha açık olduğu için tam hedefi tek satırda ayarlar. Paylaşılan çalışma alanı root:devteam‘e ait olmalı, kısıtlı yol root:root olarak kalmalıdır:

sudo chown root:devteam /srv/devworkspace
sudo chown root:root /srv/release-secrets /srv/release-secrets/deploy-key.txt

Bu sahiplik hizalamasından sonra, listenin önemli kısımları şöyle okunmalıdır:

drwxr-xr-x  root devteam  /srv/devworkspace
drwxr-xr-x  root root     /srv/release-secrets
-rw-r--r--  root root     /srv/release-secrets/deploy-key.txt

permissions  owner  group

💡 İpucu: Kısıtlı sırları grup tarafından yazılabilir çalışma alanının dışında tutun. Bu, kurulumun anlaşılmasını kolaylaştırır ve başlangıç seviyesi onboarding akışında yardımcı olmayan karmaşık dizin yazma kenar durumlarından kaçınır.

Bu noktada, sahiplik Linux’a her yolun kime bağlı olduğunu söyler. Son adım, bu sahibinin, bu grubun ve diğer herkesin orada gerçekte ne yapabileceğini tanımlamaktır.

Adım 4: İşe Uygun İzinleri Ayarlayın

Sahiplik hizalandığında, artık her yol için gerçek kuralı ayarlayabilirsiniz: kimler okuyabilir, değiştirebilir veya girebilir. Önce işi düşünün, sayıları sonra. Burada tüm izin evrenini ezberlemek için çalışmıyorsunuz; bir paylaşılan çalışma alanı ve bir kısıtlı gizli alan için bir pratik kuralı ifade ediyorsunuz.

Aşağıdaki küçük matris, çoğu başlangıççının ihtiyaç duyduğu tek şeydir:

Dizin satırı tuzaktır. Bir dizinde, x “klasörü çalıştır” anlamına gelmez. Bu, o yolu girebileceğiniz veya daha derinlerdeki bir şeye giderken geçebileceğiniz anlamına gelir. Bu yüzden bir dosya teoride okunabilir görünebilir ve yine de ona giden dizin yolunu geçemezseniz pratikte başarısız olabilir.

Şimdi bu onboarding hikayesine uygun kuralları uygulayın. Takım çalışma alanı root ve devteam tarafından kullanılabilir olmalı, ancak diğerlerine kapalı olmalıdır. Gizli dizin yalnızca root’ta kalmalı ve içindeki gizli dosya yalnızca root tarafından okunabilir olmalıdır:

sudo chmod 770 /srv/devworkspace
sudo chmod 700 /srv/release-secrets
sudo chmod 600 /srv/release-secrets/deploy-key.txt

Bu sayılar ilk bakışta göründükleri kadar zor değildir, işe bağlı tuttuğunuzda. /srv/devworkspace üzerinde 770, root’un tam erişim aldığı ve devteam‘in aynı paylaşılan erişimi aldığı anlamına gelir. Diğer herkes orada hiçbir şey almaz. /srv/release-secrets üzerinde 700, yalnızca root’un o dizine girebileceği anlamına gelir. deploy-key.txt üzerinde 600, yalnızca root’un dosyayı okuyabileceği veya değiştirebileceği anlamına gelir. Önemli olan kısım aritmetik değildir. Her modun bu yol hakkında zaten yaptığınız bir kararı yansıtmasıdır.

drwxrwx---  root devteam  /srv/devworkspace
drwx------  root root     /srv/release-secrets
-rw-------  root root     /srv/release-secrets/deploy-key.txt

⚠️ Uyarı: chmod 777 gerçek bir çözüm değildir. Genellikle sahiplik veya yol tasarımının yanlış olduğu anlamına gelir, bu nedenle birisi gerçek erişim tasarımını düzeltmek yerine hatanın üzerine geniş açık izinler koyar.

Bir gelişmiş not, kasıtlı olarak kısa tutulmuştur: daha yoğun paylaşılan dizinlerde, yöneticiler bazen dizin setgid davranışını kullanır, böylece yeni oluşturulan dosyalar takım grubunu otomatik olarak devralır. Bu daha sonra yararlıdır, ancak bir takip makalesine aittir. Bu iş akışı için, düz kullanıcılar, gruplar, sahiplik ve temel rwx kuralları yeterlidir.

Adım 5: Hem Erişimi hem de Sınırları Doğrulayın

Yapılandırma işin sadece yarısıdır. İyi bir Linux onboarding sınırı da test eder. Başarı koşulu sadece “Maya bir şey yapabilir” değildir. “Maya amaçlanan işi yapabilir ve yine de kısıtlı yola giremez” olmalıdır.

Maya için yeni bir oturum açma bağlamı başlatın, ardından bir izin verilen işlemi ve bir reddedilen işlemi test edin:

su - maya
cd /srv/devworkspace
touch first-day-check.txt
ls -l /srv/devworkspace

Ardından sınırı test edin:

cd /srv/release-secrets
cat /srv/release-secrets/deploy-key.txt

Çalışma alanı testi çalışmalıdır. Maya /srv/devworkspace dizinine girebilmeli ve orada basit bir dosya oluşturabilmelidir. Sınır testi izin hatası ile başarısız olmalı ve bu başarısızlık başarı sinyalidir. En az ayrıcalık kenarları olması gerekir.

💡 İpucu: Komutlar doğru görünse bile Maya hala /srv/devworkspace kullanamıyorsa, yeni bir oturum açın ve tekrar test edin. Yeni ek grup üyeliği her zaman eski kabukların içinde tutarlı bir şekilde görünmez.

Bu, onboarding’i doğrulamanın sakin yoludur: mutlu yolu onaylayın, ardından sınırı onaylayın. Her ikisini de yaptığınızda, iş akışı teori olmaktan çıkar ve bir sonraki sunucuda da güvenebileceğiniz bir şey haline gelir.

Modeli Bozan Yaygın Hatalar

Linux izin karmaşası çoğunlukla Linux’un gizemli olmasından kaynaklanmaz. Genellikle aynı küçük kategori hatalarından gelir. Bazen kullanıcı yanlış takımda yer alır. Bazen yol sahipliği yanlıştır. Bazen gerçek sorun x anlamı hakkında yanlış bir varsayım veya uygun tasarım yerine kullanılan bir izin kısayoludur.

Aşağıdaki tablo bu karışıklığı hata ayıklamak için pratik bir yoldur:

Çoğu izin sorunu bir katmanı atlayıp çok erken chmod‘a ulaşmaktan gelir. Sorunun kimlik, takım üyeliği, sahiplik veya yol kuralı olup olmadığını bildiğinizde, çözüm çok daha belirgin hale gelir.

Pratik Sonuç

Linux erişim kontrolü, kullanıcıları, grupları ve izinleri ayrı bilgiler gibi ele almak yerine sırayla çalıştığınızda çok daha kolay hale gelir. Bu örnekte Maya tam olarak ihtiyacı olanı aldı. Gerçek bir girişi ve paylaşılan çalışma alanına takım erişimi vardır. release-secret yoluna erişimi yoktur.

Bu kontrol listesini herhangi bir Ubuntu VPS veya küçük barındırılan Linux sunucusunda kullanın:

1. Kimliği oluşturun.
2. Paylaşılan takımı atayın.
3. Yol sahipliğini ve grubunu hizalayın.
4. Bu iş için izin kuralını ayarlayın.
5. Hem erişimi hem de sınırları test edin.

Bu yeniden kullanılabilir kontrol listesidir: kimlik → takım → kural, yol hizalaması ortada yer alır, böylece kural uygulanacak doğru bir yere sahip olur. Daha derine gitmek istiyorsanız, doğal takip adımları SSH erişimi ve sudo içerir. Paylaşılan dizin desenleri ve daha geniş Linux kullanıcı/grup yönetimi aynı temele dayanır. Temel mantık değişmez; sadece bunu daha spesifik durumlara uygularsınız.