OpenAFS – oprávnění, skupiny a cache manager

11. 10. 2011 | Michal Švamberg

Články - OpenAFS – oprávnění, skupiny a cache manager  

Jedním z faktorů, na které se při výběru souborového systému hledí, jsou možnosti nastavení přístupů uživatelům. V tomto ohledu je AFS velmi propracované. Jaké práva nám AFS nabízí, jak se používají access control listy (ACL) a jak jednotlivé komponenty AFS mezi sebou komunikují, je náplní tohoto dílu.

Obsah

• Práva
• Uživatelé
• Skupiny
• Nastavujeme ACL
• Komunikace v AFS
• Závěr

Práva

AFS používá vlastní uživatele, vlastní skupiny i vlastní oprávnění. Oprávnění jsou odlišná od unixových a vůbec na ně nebere ohled. AFS sice tyto práva ukládá, ale neřídí se jimi. Totéž platí o vlastnících a skupinách. Potíže mohou nastat v případě, kdy používáte další vrstvu, kterou by klasická práva mohly vyvést z míry (například vzdálený přístup přes FUSE k AFS).

K dispozici máme tyto oprávnění, které se aplikují vždy na adresář:

READ (r)

zpřístupní obsah souborů v adresáři,

LOOKUP (l)

umožňuje zobrazení názvů souborů a adresářů (ls), prohlédnutí seznamu práv (fs listacl). Dále přístup do podadresářů (cd), pokud uvnitř podadresáře máme opět toto oprávnění,

INSERT (i)

dovolí vytvářet nové soubory a podadresáře včetně vložení kopírováním nebo přesunem,

DELETE (d)

dovoluje odstranit soubory nebo adresáře,

WRITE (w)

umožní dělat změny obsahu souborů a unixových oprávnění příkazem chmod,

LOCK (k)

povoluje programům zamykání souborů přes flock v adresáři,

ADMINISTER (a)

dovolí úpravu ACL daného adresáře. Toto právo běžně uživatelé nedostávají vyjma svých domovských adresářů.

Abychom měli snazší život, ty nejpoužívanější kombinace mají své zkratky:

write (rlidwk)

nastaví všechna práva mimo práva ADMINISTER (změna ACL),

read (rl)

umožňuje prohlížení, čtení souborů a pohyb v  adresářové struktuře,

all (rlidwka)

nastaví všechna oprávnění,

none ()

používá se pro odebrání práv, při jeho použití se odstraní položka z ACL.

Uživatelé

V systému máme zatím dva uživatele, anonymous je systémový uživatel a musíme ho strpět, druhého uživatele afsadmin jsme si vytvořili při instalaci a obdobně bychom museli vytvořit dalšího (bude v příštích dílech). Seznam uživatelů získáme z protection serveru:

~$ pts listentries -users
Name                          ID  Owner Creator
anonymous                  32766   -204    -204 
afsadmin                       1   -204    -204 

Ve jménech uživatelů je zakázáno používat dvojtečku (:) a zavináč (@). Tečka (.) je povolená, ale používá se pro oddělení jména uživatele a jeho instance, protože jeden uživatel může vlastnit více účtů, například mat a mat.admin. A samozřejmě je doporučeno vyhnout se všem ostatním ne alfanumerickým znakům (dolar, mřížka, lomítko, ...). AFS podporuje až 64 znaků dlouhé uživatelské jméno, ale obecně se doporučuje do délky 8 znaků, stále totiž existují programy, které by nemusely s delším jménem spolupracovat.

Mezi uživatele se řadí také IPv4 adresy nebo adresy celých podsítí. Klient, který pak přistupuje z takové adresy, nemusí mít vytvořený token, ale pro jeho prokázání postačí jeho IP adresa. To je výhodné použít například u web serverů, které tak snadno získají přístup ke stránkám, ke kterým mají jinak přístup pouze jejich vlastníci. Nemá smysl definovat uživatele s globální IP adresou 0.0.0.0, protože takového již máme ve formě skupiny system:anyuser. IP adresy mají ještě jedno omezení, v ACL je smíte použít pouze uvnitř skupiny, pokud je použijete přímo, pravidlo se sice vytvoří, ale nebude fungovat.

Skupiny

Předkonfigurovaných skupin je hned několik:

~$ pts listentries -groups
Name                          ID  Owner Creator
system:administrators       -204   -204    -204 
system:backup               -205   -204    -204 
system:anyuser              -101   -204    -204 
system:authuser             -102   -204    -204 
system:ptsviewers           -203   -204    -204 

Identifikátor (ID) je záporný pro skupiny, kdežto uživatelé jej mají vždy kladný. Ten, kdo je ve skupině system:administrators, se tváří pro AFS obdobně jako superuživatel na stanici. Jeho velkou výhodou je, že při změnách ACL se nekontroluje právo ADMINISTER. A tak pokud někam nemáte přístup, stačí si jej přidělit. Další výhody jsou v provádění systémových změn v AFS (práce s volumy, s uživateli, nastavení zálohování, přístup k logům, ...). To, že jsme mohli zatím provádět všechny operace, bylo díky přiřazení uživatele afsadmin do skupiny system:administrators.

~$ pts membership system:administrators
Members of system:administrators (id: -204) are:
  afsadmin

Do skupiny system:anyuser automaticky patří každý, kdo se „netrefí“ do našeho nastavení. Může to být klient z cizí buňky nebo klient bez tokenu (nebo s vypršeným tokenem). Jde o obdobu other u unixových oprávnění. Do této skupiny se uživatelé ručně nepřidávají.

Skupina system:authuser se automaticky použije pro každého, kdo se dokázal ověřit pro naši AFS buňku. Můžeme tedy snadno odfiltrovat cizí od vlastních uživatelů, což se hodí například pro přístup k softwaru. Takový uživatel musí mít platný token. Ani do této skupiny se uživatele ručně nepřidávají.

Nastavujeme ACL

V každém adresáři je pouze omezený počet záznamů pro ACL (přibližně 20), avšak počet uživatelů ve skupině není omezen. Pro nastavení čtení všem uživatelům naší buňky provedeme příkazem fs setacl:

~$ cd /afs

/afs$ fs listacl .
Access list for . is
Normal rights:
  system:administrators rlidwka

/afs$ fs setacl . system:anyuser read

/afs$ fs listacl .
Access list for . is
Normal rights:
  system:administrators rlidwka
  system:anyuser rl

Pokud chcete vyzkoušet, že tomu opravdu tak je, stačí zničit token, na což se používá příkaz unlog:

/afs$ mkdir /afs/foo.bar/test

/afs$ find .
.
./foo.bar
./foo.bar/test

/afs$ unlog

/afs$ find .
.
./foo.bar
find: `./foo.bar': Permission denied

Chyba je způsobena tím, že jsme oprávnění nastavili pouze v adresáři /afs, ale nikoliv v adresáři /afs/foo.bar, proto to opravíme a vytvoříme adresář test2, napřed si ale znovu vytvoříme token z  platného lístku Kerberos:

/afs$ aklog

/afs$ fs setacl foo.bar system:anyuser read

/afs$ mkdir /afs/foo.bar/test2

/afs$ unlog

/afs$ find .
.
./foo.bar
./foo.bar/test
find: `./foo.bar/test': Permission denied
./foo.bar/test2

Tentokrát se find dostal do adresáře test2, protože zdědil ACL nastavení podle nadřazeného adresáře. Ovšem adresář test vznikl ještě před nastavením oprávnění pro system:anyuser a tak jej nemohl zdědit. V takových případech se s oblibou používá find:

/afs$ aklog

/afs$ find . -noleaf -type d -exec fs setacl {} system:anyuser read \;

/afs$ unlog

/afs$ find . 
.
./foo.bar
./foo.bar/test
./foo.bar/test2

Parametrem -noleaf u findu vypneme optimalizaci, která u AFS nemusí fungovat správně, vizte man find. Na závěr se sluší, abychom po sobě uklidili:

/afs$ aklog

/afs$ rmdir /afs/foo.bar/test /afs/foo.bar/test2

Komunikace v AFS

Na obrázku je znázorněná komunikace mezi jednotlivými komponentami AFS, pokud se pokusíme dostat do adresáře /afs/foo.bar/common/. Operační systém se postupně bude prokousávat jednotlivými adresáři. Napřed se pokusí zalogovat do adresáře /afs. Požadavek předá AFS klientovi a ten se (v případě naší konfigurace) pokusí najít kořenový volume root.afs v domovské buňce. Ale zná pouze adresy databázových serverů, proto (krok 1 na obrázku) položí dotaz do databáze VLDB, aby zjistil, na jakých souborových serverech je dostupný volume root.afs. Vlserver odpoví seznamem serverů a jeho partitionů (spodní část výpisu u příkazu vos examine).

Cache manager klienta se podívá na seznam preferencí (fs getserverprefs), který si průběžně buduje na základě vzdálenosti adres a konektivity. Ten porovná se seznamem volumů a vybere to nejlepší umístění. V našem případě to je file server napravo. Na něj se obrátí s požadavkem o potřebná data volumu (2).

File server přečte ACL ve volumu a zeptá se ptserveru (3), zda daný uživatel má na to oprávnění, file server totiž nezná obsah skupin. Pokud dostane kladnou odpověď, pošle (4) klientovi informaci o volumu a povolí mu vstup do adresáře. Cache manager předá informaci operačnímu systému a ten se zkusí zalogovat do adresáře foo.bar (mount point je součástí volumu root.afs). A celý cyklus se opakuje, klient se zeptá VLDB (5), obrátí se na nejvýhodnější souborový server (6) a ten si ověří práva u ptserveru (7). V případě úspěchu dostane klient data (8) a operační systém se může pokusit dostat do dalšího adresáře stejným postupem.

Z popisu komunikace vyplývá jeden bezpečnostní problém – data, která má cache manager odložená na disku ve /var/cache/openafs, nejsou nijak chráněna proti přístupu superuživatele, protože jsou uložena na běžném souborovém systému. Ztížit přístup k těmto datům můžete zapnutím cachování do paměti v /etc/openafs/afs.conf.

Vrátíme se ještě k preferencím AFS klienta, ten je používá na to, aby našel nejlépe umístěný file nebo volume location server. Detaily se nebudeme zabývat, a tak čím nižší číslo, tím lepší. Pokud má cache manager na výběr z více serverů, podívá se do seznamu a vybere ten s nejnižší hodnotou, pokud se mu jej nepodaří kontaktovat, vybere server s druhou nejnižší hodnotou a tak dále. Jakmile si hodnotu jednou cache manager nastaví, už ji nemění, ale při novém startu si tabulku vybuduje znovu. Je možné ji přenastavit příkazem fs setserverprefs, ideálně dát do skriptu po nastartování AFS klienta. Na výpisu vaší buňky můžete nalézt něco podobného:

~$ $ fs getserverprefs -numeric
10.10.10.1                                          5008
192.168.1.101                                       5011

Cache manager umí uložit až 15 rozhraní pro každý server, zde je vidět virtuální rozhraní eth0:10 a rozhraní eth0 nakonfigurované od DHCP.

Závěr

Správa skupin a jejich oprávnění je velmi silná stránka AFS, bohužel na ni nejsou uživatelé příliš zvyklí a občas nechápou, že to, co si nastaví svými oblíbenými příkazy, nějak nezabírá. V článku byly použity některá zjednodušení v rámci kompromisu za zachování srozumitelnosti. Také jsme zatím vynechali propojení uživatelských účtů na Kerberos, o tomto tématu bude samostatný díl.

Všem výše uvedeným věcem (včetně předchozích dílů) se budeme věnovat prakticky hned příště, kde se pokusím zušlechtit naši AFS buňku.

Seriál OpenAFS (dílů: 11)

První díl: OpenAFS – úvod, poslední díl: OpenAFS – zálohování do volumů.
Předchozí díl: OpenAFS – cesta v AFS stromu
Následující díl: OpenAFS – prakticky o volumech a replikaci