Identifikace a autorizace - MujMAC.cz - Apple, Mac OS X, Apple iPod

22. května 2006, 00.00 | Dnes si povíme trochu více o identifikaci (tedy jakým způsobem si Mac OS X pamatuje který uživatel zadal které heslo) a autorizaci (tedy jak určí, co který uživatel smí a co nesmí dělat).

Minule jsme se podrobně zabývali tím, jak v Mac OS X probíhá autentifikace uživatele – jinými slovy, jak je to s hesly. Dnes si povíme trochu více o identifikaci (tedy jakým způsobem si Mac OS X pamatuje který uživatel zadal které heslo) a autorizaci (tedy jak určí, co který uživatel smí a co nesmí dělat). Dnes (a ještě příště) to tedy bude malinko "odbornější"; pak se ale opět vrátíme do GUI :)

Identifikace v Mac OS X

Jak jsme si řekli minule, uživatel je interně v Mac OS X identifikován svým číslem, zatímco v GUI (nebo v Terminálu) nám systém zobrazuje jeho jméno.

Základní princip identifikace spočívá v tom, že kterýkoli proces (tj. "běžící program či aplikace") je vždy pevně spojen s číslem uživatele, jemuž patří. Kdykoli se pak takový proces pokusí o nějakou akci, systém ji nejprve autorizuje (nebo zakáže). Pokud proces spouští jiný proces, identifikace uživatele se jednoduše dědí.

Pokud jsme se tedy úspěšně přihlásili (proběhla autentifikace), Mac OS X nám spustí základní program – ten se jmenuje "loginwindow" – s naším uživatelským číslem. Ten pak automaticky spustí všechny další potřebné programy, od doku až po Finder; ty mohou podle potřeby spouštět programy další, ale díky výše popsanému dědění jsou vždy všechny spojeny s naší identifikací, takže systém může správně autorizovat všechny operace. Přitom není problém, aby zároveň na témže počítači běžela řada jiných (nebo i týchž) programů v rámci konta jiného uživatele – tedy spojených s jiným číslem; ty pak samozřejmě mohou být autorizovány odlišně, a budou obecně oprávněny k jiným operacím, než procesy "naše".

Ve skutečnosti je tento systém malinko složitější: někdy totiž může být zapotřebí, aby proces (samozřejmě pod přísnou kontrolou) mohl využít širší práva, než jimiž disponuje jeho uživatel – chceme-li např. přímo z Finderu zasáhnout do některé systémové oblasti, je to obecně možné, musíme se však pro každou takovou akci znovu autentifikovat ve Finderu jako administrátor. Pro takovéto případy mohou proces doprovázet dvě uživatelská čísla:

• tzv. UID – identifikace uživatele, jemuž proces skutečně patří;
• tzv. EUID (effective UID) – identifikace uživatele, jehož práva má proces dočasně propůjčena.

Je zřejmé, že proces si nemůže EUID nastavovat, jak se mu zachce; Mac OS X umožňuje nastavit EUID pouze (a) na základě autentifikace uživatele, jehož EUID máme použít, nebo (b) pokud program patří uživateli, jenž explicitně určil, že při jeho spuštění svá práva uživateli propůjčí, nebo (c) na základě speciálních práv administrátora.

Případ (a) je zřejmý – vlastně se nijak zásadně neliší od možnosti, že bychom program spustili přímo z konta jiného uživatele, jen je pohodlnější.

Varianta (b) – tzv. "setuid bit" – velmi často slouží pro programy, jež jsou speciálně určeny k provádění systémových služeb: administrátor může připravit program, který dělá něco, co běžný uživatel obecně dělat nesmí – třeba prohlížet systémové oblasti, kde jsou záznamy o běžících procesech. Administrátor si samozřejmě dá pozor na to, aby to zmíněný program dělal korektně a bez nebezpečí zneužití – třeba program ps zobrazuje procesy tak, aby to nemohlo vést k napadení systému. Administrátor pak přidělí programu ps speciální příznak ("setuid bit"), který znamená, že při spuštění tohoto programu bude jeho EUID patřit vlastníkovi programu (tj. administrátorovi) a nikoli uživateli, který program spustil – a díky tomu program může pracovat a využívat systémových služeb, pro něž je autorizován pouze administrátor.

Speciální varianta (c) pak je obvykle doprovázena novou autentifikací administrátora (nestačí tedy to, že se admin již autentifikoval jednou), a blíže se na ni podíváme zanedlouho, až si budeme vysvětlovat kdo to je uživatel "root".

Autorizace v Mac OS X

Naprostá většina operací, pro něž Mac OS X standardně zajišťuje autorizaci – jinými slovy, jež jsou chráněny před neoprávněnými uživateli – je zabezpečena prostřednictvím systému souborů. To je systém, koncepčně převzatý z Unixu, a velmi praktický: jde v zásadě o to, že cokoli, co je má zapotřebí omezený přístup, má svou položku v systému souborů – vedle samotných souborů a složek, pro něž je autorizace samozřejmě zapotřebí, zde jsou i věci jako odkazy na zařízení (takže lze určit, kdo smí užívat třeba sériového rozhraní) nebo na systémovou paměť.

Unixová práva

Základem autorizace v systému souborů jsou standardní unixová přístupová práva. Každý objekt (soubor, složka, zařízení...) má tři trojice přepínačů, jež určují co se s objektem smí a co se nesmí dělat. Prvá trojice určuje práva vlastníka objektu; druhá se týká skupiny (o skupinách si trochu více řekneme za chvilku); třetí pak platí pro všechny ostatní uživatele.

Přepínače v každé trojici jsou tradičně nazývány "rwx":

• prvnímu z nich říkáme "r", protože určuje právo čtení ("Read");
• druhý se nazývá "w" pro právo zápisu ("Write");
• třetí je "x" pro právo použití ("eXecute").

Nejjednodušší to je s obyčejnými soubory: je-li k dispozici přepínač "r", smíme číst obsah souboru. Pokud přepínač "r" k dispozici není, jakýkoli příkaz nebo služba, jež by se pokusily jakkoli číst obsah souboru, skončí chybou a nic nepřečtou. Podobně je tomu s přepínačem "w": je-li k dispozici, můžeme obsah souboru měnit; jestliže však právo "w" nemáme, skončí jakýkoli pokus změnit obsah souboru chybou, a obsah souboru se samozřejmě nezmění.

S přepínačem "w" bývá určitá komplikace: začátečníci, zmateni atributy souborů např. v MS DOSu (nebo, to se ví, v Mac OS Classic), často předpokládají, že nemáme-li k dispozici právo "w", nesmíme soubor smazat. To je ovšem úplný nesmysl: pročpak by tomu tak mělo být? Nemáme-li "w", nesmíme měnit obsah souboru; protože při rušení souboru se jeho obsah nijak nemění, mazat klidně můžeme.

S přepínačem "x" to je i není jednoduché: máme-li jej k dispozici, můžeme soubor použít; jestliže jej nemáme, soubor použít nemůžeme. To je samozřejmé a prosté, jenže... co to znamená "použít soubor"? Inu

• u souborů, jež obsahují programy (a mají tedy speciální formát, který se mimochodem nazývá Mach-O), je to jasné – ty se prostě spustí;
• textové soubory se "spouštějí" také, a to tak, že se předají shellu jako seznam příkazů, jež má shell provést (tzv. skript);
• pro ostatní soubory přepínač "x" nemá smysl.

Řadě lidí se na první pohled zdá způsob, jímž se interpretují přepínače "r", "w" a "x" pro práci se složkami, trochu komplikovaný. Ve skutečnosti tomu tak ale vůbec není: stačí si jen uvědomit, že složka vlastně není nic jiného, než soubor, obsahující jména vnořených souborů a složek – a význam přístupových práv se hned stane naprosto jasným:

• jestliže tedy přepínač "r" dovoluje čtení, znamená to, že si smíme "přečíst obsah složky" – jinými slovy, můžeme zjistit, které objekty složka obsahuje. Pokud právo "r" nemáme, obsah složky číst nesmíme; neexistuje tedy způsob, jak zjistit, co složka obsahuje: příkaz ls (stejně jako všechny ostatní způsoby, jak zjistit obsah složky) prostě vrátí chybu;
• přepínač "w" dovoluje změnu, v našem případě tedy změnu složky samotné. Kdy se mění složka (je-li "souborem, obsahujícím jména vnořených souborů a složek")? Samozřejmě, kdykoli, když bychom chtěli některý z objektů, jež ve složce leží, přejmenovat či smazat, nebo kdybychom do složky chtěli přidat nový objekt. To jsou tedy přesně akce, jež nesmíme dělat nad objekty ve složce, pro niž nemáme právo "w";
• pro začátečníky bývá asi nejzáhadnější přepínač "x": jakýpak může mít smysl "použít" složku? Ale samozřejmý: používáme ji přece pro přístup k objektům, které leží uvnitř! Máme-li tedy k dispozici přepínač "x", můžeme otevřít soubor, který už ve složce leží, nebo třeba můžeme přejít do vnořené složky.

Přepínače "r", "w" a "x" tak, jak jsme je právě popsali, jsou sice velmi silné, ale přece jen nestačí pokrýt všechny situace, se kterými se v moderních operačních systémech můžeme setkat. Proto existují trochu speciální přepínače "s" a "t".

O přepínači "s" jsme mluvili před chvilkou – to je právě ten "setuid bit", speciální alternativa "x", jež říká nejen "můžeš tento soubor použít (spustit)", ale navíc "já ti k tomu propůjčuji svá práva".

Přepínač "t" ("sTicky") je také speciální alternativa "x", jež naopak má (v Mac OS X) smysl pouze pro složky, a oproti "x" znamená určité omezení: značí, že smazat soubor (uvnitř dané složky) je možné jen pod podmínkou, že ten, kdo jej chce smazat, je buď vlastníkem daného souboru, nebo vlastníkem celé složky (a samozřejmě má právo "w"). Díky "sticky bitu" je možné pracovat se složkami, do kterých sice může zapsat kdokoli cokoli se mu zachce a smazat to po sobě, avšak uživatelé si v nich nemohou soubory rušit navzájem. Je zřejmé, že to je ideální pro různé dočasné soubory ve sdílených složkách, a skutečně standardní složka "/tmp/" "sticky bit" používá.

Podívejme se na několik příkladů z Terminalu (Finder sice přístupová práva zobrazuje také – v panelu "Ownership & Permissons" v Get Info –, užívá však daleko méně přehledný způsob, v němž se lze poměrně špatně vyznat): práva jsou zde zobrazena jako tři trojice písmenek "rwxrwxrwx", pokud patřičné oprávnění není k dispozici, písmenko je nahrazeno znakem "-" (před nimi je ještě jeden znak, určující typ objektu – "d" pro složku, "-" pro běžný soubor):

Složka "Documents" je k dispozici komukoli – všichni mají práva "r" a "x". Jen vlastník (jak vidíme ve třetím sloupci, uživatel "apple") však smí obsah složky měnit. Obdobný případ se souborem je "Nezamceno": číst jeho obsah smí kdokoli, ale jen vlastník jej může měnit. Třetím obdobným příkladem je program "q": kdokoli jej smí číst, kdokoli jej smí spustit, ale jen vlastník smí měnit jeho obsah.

Jinak je tomu se složkou "Moje soubory": ta je přístupná pouze vlastníkovi. Nikdo jiný nesmí složku ani číst, ani měnit, ani žádným jiným způsobem používat.

Složka "Public" je vlastníkovi přístupná bez omezení; zajímavá však je dvojice práv "wx", jež jsou k dispozici "všem ostatním": ty znamenají, že kdokoli může obsah složky měnit ("w") a také používat soubory či složky do ní uložené ("x"), ale nikdo nevidí, co ve složce doopravdy je. Finder takovéto nastavení práv označuje jako "drop box".

Ukažme si i několik systémových souborů:

Standardní unixové programy cat nebo ls smí kdokoli spouštět i číst; nikdo však nesmí měnit jejich obsah (dokonce ani "root", který je jejich vlastníkem – ten ovšem může jako jediný jejich přístupová práva kdykoli změnit).

Programy su a sudo ovšem potřebují přístup k administrátorským prostředkům, aby samy mohly po kontrole hesla spouštět další programy v rámci konta kteréhokoli uživatele; proto mají nastaven bit "s" ve skupině práv vlastníka, což znamená, že ať program spustí kdo chce, jeho efektivním vlastníkem bude "root". Příkaz sudo využívá maximálního možného zabezpečení: žádná jiná práva než "x" (respektive "s") nikomu nedává. Nejenže tedy do něj nikdo nesmí zasahovat, ale nikdo jej nesmí ani číst.

Skupiny

Důvodem pro zavedení skupin byla potřeba spravovat objekty, ke kterým má mít speciální přístup nějaká skupina více uživatelů: typickým příkladem může být třeba projekt, na kterém spolupracuje několik programátorů; jiný příklad může být rozsáhlý dokument HTML, ve kterém různí autoři spravují různé části, ale všichni potřebují mít zároveň přístup k základnímu obsahu se všemi odkazy. V takovýchto případech zřejmě nestačí to, co dosud známe – tj. nějaká práva pro vlastníka, jiná pro všechny ostatní –, leda bychom chtěli k projektu pustit naprosto kohokoli, a to většinou není právě žádoucí. Potřebujeme tedy navíc speciální práva pro skupinu uživatelů, a přesně to také unixové systémy nabízejí.

Stejně jako má každý objekt svého jednoznačného vlastníka, patří i právě jedné, jednoznačně určené skupině; podíváme-li se na příklady nahoře, patřily uživatelské objekty skupině "staff", kdežto systémové skupině "wheel".

(Mimochodem, stejně jako je tomu u uživatelů, i skupiny jsou ve skutečnosti určeny čísly. Mac OS X ovšem tato čísla převádí na odpovídající jména kdykoli to je možné.)

Každý uživatel může být členem kterékoli skupiny, nebo, chcete-li se na to dívat z druhé strany, kterákoli skupina může obsahovat libovolné množství uživatelů. Chceme-li však členství uživatelů ve skupinách změnit, není to tak jednoduché. Podle zdravého rozumu by seznam skupin měl být součástí panelu "Accounts" v aplikaci "System Preferences"; bohužel tomu tak není. Pro určení skupin proto musíme použít přímo aplikaci "NetInfo Manager" (nebo řádkové příkazy pro práci s databází NetInfo v terminálu). Aplikaci NetInfo Manager najdeme ve složce "/Applications/Utilities". Po jejím spuštění je to už celkem jednoduché: seznam skupin nalezneme v adresáři "/groups", jak ukazuje obrázek:

kde jsou pro nás důležité klíče "gid" (ten obsahuje číslo skupiny), "name" a "users" – v něm je seznam jmen uživatelů, kteří jsou členy dané skupiny.

S přístupovými právy už je to pak poměrně jednoduché. Má-li Mac OS X zjistit, zda lze povolit přístup k nějakému objektu, podívá se na EUID procesu, který se o akci pokouší:

• je-li uživatel s číslem EUID vlastníkem objektu, použije se první trojice přístupových práv;
• jinak systém ověří, zda je uživatel s číslem EUID členem skupiny, jež objekt vlastní; je-li tomu tak, použije druhou trojici přístupových práv;
• jinak použije třetí trojici přístupových práv.

ACL

Existují případy, v nichž standardní unixová přístupová práva – dokonce ani s využitím skupin – nenabízejí dostatečnou flexibilitu. Pro ně Mac OS X nabízí tzv. ACL (Access Control Lists) – zcela obecný a flexibilní autorizační systém, jehož prostřednictvím lze libovolnému uživateli dopřát či zapovědět libovolné právo k libovolnému objektu v systému souborů, zcela nezávisle na ostatních. S využitím ACL lze dokonce práva dědit – můžeme tedy např. určit, že soubor smí být čten uživatelem "ocs" právě tehdy, má-li "ocs" právo číst jeho nadřízenou složku; naproti tomu "admin" smí soubor číst vždy, a "maler" nikdy.

Podrobný popis konkrétních služeb ACL by přesáhl rámec tohoto seriálu; zmiňme se pouze o tom, že v klientském Mac OS X jsou standardně vypnuty (avšak pro každý disk – přesněji volume – je lze zapnout příkazem fsaclctl), a že přístup k nim máme pouze prostřednictvím standardních terminálových příkazů ls a chmod – ACL nejsou v GUI ani zobrazovány, ani je odtud nelze řídit. Další informace lze najít v odpovídajících manuálech ("man chmod"; příkaz fsaclctl sice nemá manuálovou stránku, avšak spustíme-li jej bez argumentů, vypíše nápovědu).

Příště...

... se podíváme pořádně na zoubek administrátorům a seznámíme se s panem rootem, superuživatelem.