Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
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ář:
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í,
chmod
,
flock
v adresáři,
Abychom měli snazší život, ty nejpoužívanější kombinace mají své zkratky:
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.
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í.
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
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.
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.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: