'Sahip' izinlerinin var olmasının bir nedeni var mı? Grup izinleri yeterli değil mi?

Sanırım dosya izinlerinin Linux'ta nasıl çalıştığını anlamayı tercih ediyorum. Ancak, neden üç seviyeye ayrıldıklarını ikiye ayırmadıklarını anlamıyorum.

Aşağıdaki sorunların cevaplanmasını istiyorum:

• Bu kasıtlı tasarım mı, yoksa yama mı? Yani - bazı gerekçelerle birlikte tasarlanıp oluşturulan sahiplik / grup izinleri miydi yoksa bir ihtiyaca cevap vermek için birbiri ardına geldiler mi?
• Kullanıcı / grup / diğer programın yararlı olduğu ancak grup / diğer programların yeterli olmayacağı bir senaryo var mı?

İlk cevaplar ya ders kitapları ya da resmi tartışma panoları vermelidir.

Göz önünde bulundurduğum davaları kullan:

• özel dosyalar - kullanıcı başına bir grup yaparak kolayca elde edilebilir, çoğu sistemde olduğu gibi.
• sadece sahibinin (örn. sistem servisi) bir dosyaya yazmasına izin vermek, sadece belirli bir grubun okumasını sağlamak ve diğer tüm erişimi reddetmek - bu örnekteki sorun, bir grubun yazma erişimine sahip olma gereksinimi olduğunda , kullanıcı / group / other bununla başarısız olur. Her ikisinin de yanıtı ACL kullanıyor ve IMHO, sahiplik izinlerinin varlığını haklı göstermiyor.

NB Bu soruyu superuser.com'da kapattıktan sonra rafine ettim .

EDIT düzeltildi "ancak bir grup / sahip programı" "" / grup / diğer ... "için yeterli olmayacak.

Tarihçe

Başlangıçta Unix yalnızca sahip olan kullanıcı ve diğer kullanıcılar için izinlere sahipti: hiçbir grup yoktu. Özellikle Unix sürüm 1'in belgelerine bakın chmod(1). Bu nedenle geriye dönük uyumluluk, başka bir şey değilse, sahip olan kullanıcı için izinler gerektirir.

Gruplar daha sonra geldi. Bir dosyanın izinlerine birden fazla grup dahil edilmesine izin veren ACL'ler daha sonra geldi.

Etkileyici güç

Bir dosya için üç izne sahip olmak, çok düşük bir maliyetle (ACL'lerden çok daha düşük), sadece iki taneden daha ince taneli izinlere izin verir. Örneğin, bir dosya modu olabilirrw-r----- : yalnızca sahibi olan kullanıcı tarafından yazılabilir, bir grup tarafından okunabilir.

Başka bir kullanım durumu, sadece bir grup tarafından çalıştırılabilen setuid çalıştırılabilir dosyalarıdır. Örneğin, rwsr-x---sahip olduğu moda sahip bir programroot:admin yalnızca admingruptaki kullanıcıların bu programı kök olarak çalıştırmasına izin verir .

“Bu programın ifade edemeyeceği izinler var” aleyhine korkunç bir argüman. Uygulanacak kriter şudur, maliyeti haklı çıkaran yeterince açık ortak durumlar var mı? Bu durumda, özellikle kullanıcı / grup / diğer triptik için diğer nedenler göz önüne alındığında, maliyet asgari düzeydedir.

Basitlik

Kullanıcı başına bir gruba sahip olmak, küçük fakat önemsiz olmayan bir yönetim ek yüküne sahiptir. Özel bir dosyanın son derece yaygın olması durumunda buna bağlı olmamak iyidir. Özel bir dosya oluşturan bir uygulama (örneğin bir e-posta gönderim programı), yapması gereken tek şey dosyaya 600 kipinin verilmesi olduğunu bilir. böyle bir grup veya birden fazla yoksa ne yapmalı?

Başka bir yönden geliyorsa, bir dosya gördüğünüzü ve izinlerini denetlemek istediğinizi varsayalım (yani, ne olması gerektiğini kontrol edin). Grup tanımlarını izlemeniz gerektiğinden “yalnızca kullanıcıya erişilebilir, tamam, sonraki” seçeneğine gidebileceğiniz zaman çok daha kolaydır. (Bu tür karmaşıklık, ACL'ler veya yetenekler gibi gelişmiş özelliklerden yoğun şekilde yararlanan sistemlerin bütünüdür.)

Diklik

Her bir işlem, belirli bir kullanıcı ve belirli bir grup olarak dosya sistemi erişimi gerçekleştirir (ek bir grupları destekleyen modern birimlerde daha karmaşık kurallarla). Kullanıcı root testi (kullanıcı kodu 0) ve sinyal dağıtım izni (kullanıcı bazlı) dahil olmak üzere pek çok şey için kullanılır. Süreç izinlerinde kullanıcıları ve grupları ayırt etmek ve dosya sistemi izinlerinde kullanıcıları ve grupları ayırt etmek arasında doğal bir simetri vardır.

Bu kasıtlı tasarım mı, yoksa yama mı? Yani - bazı gerekçelerle birlikte tasarlanıp oluşturulan sahiplik / grup izinleri miydi yoksa bir ihtiyaca cevap vermek için birbiri ardına geldiler mi?

Bir dosyadaki kullanıcı / grup / diğer izinler orijinal Unix tasarımının bir parçasıdır.

Kullanıcı / grup / diğer programın yararlı olduğu ancak grup / mal sahibi programının yeterli olmayacağı bir senaryo var mı?

Evet, neredeyse her senaryoda güvenlik ve erişim kontrolünün nerede önemli olduğunu hayal edebiliyorum.

Örnek: Bir sistemde sadece ikili çalıştırma erişimi için bazı ikili dosyalar / komut dosyaları vermek otherve okuma / yazma erişimini sınırlı tutmak isteyebilirsiniz root.

Yalnızca sahip / grup izinlerine sahip bir dosya sistemi izin modeli için aklınız ne olduğundan emin değilim. Bir otherkategori olmadan güvenli bir işletim sistemine nasıl sahip olabilirsiniz bilmiyorum .

DÜZENLEME: Diyelim ki, burada kastedilen group/otherizinlerin gerekli olduğunu varsayalım, o zaman şifreleme anahtarlarını yönetmek için ya da yalnızca doğru kullanıcıların posta biriktirmelerine erişebilecekleri bir yol geliştirmeyi öneriyorum. Özel bir anahtarın kesinlikle user:usermülkiyete ihtiyaç duyabileceği durumlar vardır, ancak mülkiyeti vermenin anlamlı olduğu durumlar user:group.

özel dosyalar - kullanıcı başına bir grup yaparak kolayca elde edilebilir, çoğu sistemde olduğu gibi.

Bunun kolayca yapıldığı kabul edilir, ancak bir othergrubun varlığı ile de aynı şekilde kolayca yapılır .

sadece sahibinin (örn. sistem servisi) bir dosyaya yazmasına izin vermek, sadece belirli bir grubun okumasını sağlamak ve diğer tüm erişimi reddetmek - bu örnekteki sorun, bir grubun yazma erişimine sahip olma gereksinimi olduğunda, kullanıcı / group / other bununla başarısız olur. Her ikisinin de yanıtı ACL kullanıyor ve IMHO, sahiplik izinlerinin varlığını haklı göstermiyor.

otherUnix dosya sistemi izinlerinde bir kategorinin mantıksal gerekliliği konusundaki görüşümü yinelemiş gibi görünen ifadenizi vurguladım .

Düşündüğünüz gibi bir dosya sistemi tasarımı (söyleyebileceğim şeyden) güvensiz ya da hantal olur. Unix, çok zeki insanlar tarafından tasarlandı ve bence modellerinin en iyi güvenlik ve esneklik dengesini sağladığını düşünüyorum.

Bu kasıtlı tasarım mı, yoksa yama mı? Yani - bazı gerekçelerle birlikte tasarlanıp oluşturulan sahiplik / grup izinleri miydi yoksa bir ihtiyaca cevap vermek için birbiri ardına geldiler mi?

Evet, UNIX'te erken günlerden beri var olan kasıtlı bir tasarım. Belleğin KB olarak ölçüldüğü sistemlerde uygulandı ve CPU'lar bugünün standartlarına göre oldukça yavaştı. Bu tür aramaların boyutu ve hızı önemliydi. ACL'ler daha fazla alan gerektirecek ve daha yavaş olacaktı. İşlevsel olarakeveryone grup diğer güvenlik bayraklarıyla temsil edilir.

Kullanıcı / grup / diğer programın yararlı olduğu ancak grup / mal sahibi programının yeterli olmayacağı bir senaryo var mı?

Genellikle dosya erişimi için kullandığım izinler şunlardır: (Basitlik için bit değerleri kullanıyorum ve bu yüzden genellikle bunları ayarladım).

• 600 veya 400 : Yalnızca kullanıcı erişimi (ve evet, kullanıcıya yalnızca salt okunur erişim veriyorum).
• 640 veya 660 : Kullanıcı ve grup erişimi.
• 644, 666veya664 : Kullanıcı, grup ve diğer erişim. Herhangi iki seviyeli izin şeması, bu üç vakanın sadece ikisini idare edebilir. Üçüncüsü ACL'leri gerektirecektir.

Yaygın olarak kullandığım dizinler ve programlar için:

• 700 veya 500 : Sadece kullanıcı erişimi
• 750 veya 710 : Yalnızca grup erişimi
• 755, 777, 775, Veya 751: Kullanıcı, grup ve diğer erişim. Aynı yorumlar dosyalar için de geçerlidir.

Yukarıdakiler en yaygın kullanılanlardır, ancak kullandığım izin ayarlarının kapsamlı bir listesi değildir. Bir grupla birleştirilen yukarıdaki izinler (bazen dizinlerde yapışkan bir grup biti bulunan) bir ACL kullandığım tüm durumlarda yeterli olmuştur.

Yukarıda belirtildiği gibi, izinleri bir dizin listesinde listelemek çok kolaydır. ACL'ler kullanılmıyorsa, erişim izinlerini yalnızca bir dizin listesiyle denetleyebilirim. ACL tabanlı sistemler ile çalışırken, izinleri doğrulamayı veya denetlemeyi çok zor buluyorum.

Kullanıcı / grup / diğer izin sistemi, EKL'lerin icat edilmesinden önce tasarlanmıştır. UNIX'in ilk günlerine dayanıyor, bu nedenle sorunun ACL'lerle çözülmesi gerektiğini söyleyemezsiniz. ACL kavramı açık görünse bile, sabit bir miktar yerine her dosyada değişken miktarda izin bilgisi saklamak ve yönetmek için kayda değer bir [gün başına] ek yük tutarı içermiştir.

Her şey için ACL'leri kullanmak, aynı zamanda "bir bakışta" gösterilebilecek izin bilgileri için iyi tanımlanmış bir alt gruba sahip olmadığınız anlamına gelir. Çıktısı ls -l, standart (kullanıcı / grup / diğer) izinleri, kullanıcı ve grubun adını ve bunlarla ilişkili bir ACL'ye sahip girişlerde, hepsi bir satırda ek bir gösterimi (örn. +Veya @işaret) gösterir. Sisteminiz, eşdeğer işlevsellik sağlamak için ACL'deki "ilk iki" grubu tanımlamasını ister.

Ek bir nokta olarak, bir dosyanın hala UNIX modelinde bir sahibi olması gerekir , çünkü UNIX ACL'lerinin ACL'yi kimin değiştirmesine izin verildiğini sağlamaz.