Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
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: