Historie
Původně měl Unix oprávnění pouze pro vlastnícího uživatele a pro ostatní uživatele:neexistovaly žádné skupiny. Viz dokumentaci k Unixu verze 1, zejména chmod(1) . Takže zpětná kompatibilita, pokud nic jiného, vyžaduje oprávnění pro vlastnícího uživatele.
Skupiny přišly později. ACL umožňující zahrnout více než jednu skupinu do oprávnění souboru přišla mnohem později.
Výrazová síla
Mít tři oprávnění pro soubor umožňuje jemnější oprávnění než mít pouze dvě, a to za velmi nízkou cenu (mnohem nižší než ACL). Soubor může mít například režim rw-r----- :zapisovatelný pouze vlastníkem, čtení pro skupinu.
Dalším případem použití jsou spustitelné soubory setuid, které jsou spustitelné pouze jednou skupinou. Například program s režimem rwsr-x--- ve vlastnictví root:admin umožňuje pouze uživatelům v admin skupiny, chcete-li tento program spustit jako root.
„Existují oprávnění, která toto schéma nemůže vyjádřit“ je hrozný argument proti. Použitelným kritériem je, existuje dostatek běžných vyjádřitelných případů, které odůvodňují náklady? V tomto případě jsou náklady minimální, zejména s ohledem na další důvody pro uživatele/skupinu/jiný triptych.
Jednoduchost
Mít jednu skupinu na uživatele znamená malou, ale ne nevýznamnou režii správy. Je dobře, že extrémně častý případ soukromého souboru na tom nezávisí. Aplikace, která vytváří soukromý soubor (např. program pro doručování e-mailů), ví, že vše, co potřebuje udělat, je dát souboru režim 600. Nemusí procházet databází skupin a hledat skupinu, která obsahuje pouze uživatele – a co dělat, když taková skupina neexistuje nebo jich je více?
Z jiného směru předpokládejme, že vidíte soubor a chcete zkontrolovat jeho oprávnění (tj. zkontrolovat, zda jsou taková, jaká by měla být). Je to mnohem snazší, když můžete přejít „dostupný pouze pro uživatele, dobře, další“, než když potřebujete sledovat definice skupin. (Taková složitost je prokletí systémů, které intenzivně využívají pokročilé funkce, jako jsou ACL nebo schopnosti.)
Ortogonalita
Každý proces provádí přístupy k souborovému systému jako konkrétní uživatel a určitá skupina (s komplikovanějšími pravidly na moderních unicích, které podporují doplňkové skupiny). Uživatel se používá pro spoustu věcí, včetně testování na root (uid 0) a oprávnění k doručování signálu (na základě uživatele). Mezi rozlišováním uživatelů a skupin v oprávněních procesu a rozlišováním uživatelů a skupin v oprávněních souborového systému existuje přirozená symetrie.
Je to záměrný návrh nebo záplata? To znamená – byla oprávnění vlastníka/skupiny navržena a vytvořena společně s nějakým zdůvodněním, nebo přicházela jedno po druhém, aby odpovídala potřebě?
Uživatelská/skupinová/jiná oprávnění k souboru jsou součástí původního unixového designu.
Existuje scénář, kdy je schéma uživatel/skupina/jiné užitečné, ale schéma skupiny/vlastníka nestačí?
Ano, prakticky každý scénář, který si umím představit, kde je důležité zabezpečení a řízení přístupu.
Příklad:Možná budete chtít udělit některým binárním souborům/skriptům v systému přístup pouze ke spuštění k other a ponechte přístup pro čtení/zápis omezený na root .
Nejsem si jistý, co máte na mysli pro model oprávnění systému souborů, který má pouze oprávnění vlastníka/skupiny. Nechápu, jak byste mohli mít bezpečný operační systém bez existence other kategorie.
UPRAVIT: Předpokládejme, že jste zde mysleli group/other oprávnění jsou vše, co by bylo potřeba, pak navrhuji vymyslet nějaký způsob správy kryptografických klíčů nebo způsob, jakým budou mít přístup k jejich poštovnímu zařazovacímu systému pouze ti správní uživatelé. Existují případy, kdy soukromý klíč může vyžadovat striktně user:user vlastnictví, ale v jiných případech, kdy má smysl dát mu user:group vlastnictví.
soukromé soubory – velmi snadno získatelné vytvořením skupiny pro každého uživatele, což se často dělá jako v mnoha systémech.
Je pravda, že to lze snadno provést, ale stejně snadno to lze provést s existencí other skupina...
povolit pouze vlastníkovi (např. systémové službě) zapisovat do souboru, povolit čtení pouze určité skupině a zakázat veškerý přístup - problém s tímto příkladem je, že jakmile je požadavkem, aby skupina měla přístup pro zápis, uživatel/skupina/ostatní s tím selže. Odpovědí pro oba je použití ACL a neospravedlňuje IMHO existenci oprávnění vlastníka.
Zvýraznil jsem část vašeho prohlášení, která, jak se zdá, opakuje můj názor na logickou nutnost other kategorie v oprávněních systému souborů Unix.
Takový návrh souborového systému, o kterém se zdá, že uvažujete (z toho, co mohu říci), by byl buď nejistý, nebo nepraktický. Unix byl navržen několika velmi chytrými lidmi a myslím, že jejich model poskytuje nejlepší možnou rovnováhu mezi bezpečností a flexibilitou.
Je to záměrný návrh nebo záplata? To znamená – byla oprávnění vlastníka/skupiny navržena a vytvořena společně s nějakým zdůvodněním, nebo přicházela jedno po druhém, aby odpovídala potřebě?
Ano, toto je záměrný návrh, který je v UNIXu přítomen od prvních dnů. Byl implementován na systémech, kde se paměť měřila v KB a CPU byly podle dnešních standardů extrémně pomalé. Důležitá byla velikost a rychlost těchto vyhledávání. ACL by vyžadovaly více místa a byly pomalejší. Funkčně everyone skupina je reprezentována ostatními bezpečnostními příznaky.
Existuje scénář, kdy je schéma uživatel/skupina/jiné užitečné, ale schéma skupiny/vlastníka nestačí?
Oprávnění, která běžně používám pro přístup k souborům, jsou:(Pro jednoduchost používám bitové hodnoty a protože je obvykle nastavuji tak.)
600nebo400:Přístup pouze pro uživatele (a ano, uděluji uživateli přístup pouze pro čtení).640nebo660:Uživatelský a skupinový přístup.644,666nebo664:Uživatelský, skupinový a další přístup. Jakékoli dvouúrovňové schéma oprávnění může zpracovat pouze dva z těchto tří případů. Třetí by vyžadoval ACL.
Pro adresáře a programy, které běžně používám:
700nebo500:Přístup pouze pro uživatele750nebo710:Přístup pouze pro skupinu755,777,775nebo751:Uživatelský, skupinový a další přístup. Platí stejné komentáře jako pro soubory.
Výše uvedené jsou nejčastěji používané, ale není to vyčerpávající seznam nastavení oprávnění, která používám. Výše uvedená oprávnění v kombinaci se skupinou (někdy s lepivým bitem skupiny v adresářích) stačila ve všech případech, kdy jsem mohl použít ACL.
Jak bylo uvedeno výše, je velmi snadné uvést oprávnění ve výpisu adresáře. Pokud se nepoužívají ACL, mohu auditovat přístupová oprávnění pouze pomocí výpisu adresáře. Když pracuji se systémy založenými na ACL, je pro mě velmi obtížné ověřit nebo auditovat oprávnění.