systemd 232

Po více než třech měsících vývoje od vydání verze 231 (zprávička) oznámil Lennart Poettering vydání verze 232 správce systému a služeb systemd (GitHub, NEWS). Novinkou je například nástroj systemd-mount (zprávička).

4.11.2016 01:11 | Ladislav Hagara | Nová verze

Komentáře

[pc2005]

Ohnivzdorné trenky nasadit :-P.

BTW to musí být strašně náročné na udržování bleeding edge distribuce, když každou chvíli nahradí nějakej GNU nástroj :-/.

[Conscript89]

každou chvíli nahradí nějakej GNU nástroj :-/.

To je mysleno na ten systemd-mount nebo na co? Jestli to neni jen takovy FUD.

[pc2005]

Jj, teda podle jména předpokládám, že to je náhrada za mount.

[Conscript89]

No, takze uz vime ze to neni ani nahrada, ani wrapper...

[skunkOS]

Třeba v Archu se nějaké změny, které by vyžadovaly uživatelský zásah a týkaly se systemd, staly snad dvakrát. To, že systemd poskytuje variantu nástroje, který funkcionalitou pokryje nějaký GNU ekvivalent se stává, ale neznamená to, že ta GNU varianta zmizí z repa.

[motyq]

problém je spíše v tom, že ó náš nejvyšší a nejchytřejší začne tyto věci nejdříve silně doporučovat a posléze ostatní silně komplikovat, že na to postupně přejdeš ať chceš nebo nechceš.

přijde mi to jako windowsizace linuxu - ve smyslu myšlení. Bude to pravděpodobně završeno systemd-system.dat a k němu cli nebo gui systemd-regedit. Pak se začnem poohlížet třeba po freebsd...

Možná se jen pletu, ale politika okolo systemd se mi vůbec nelíbí.

[skunkOS]

Mě se ta politika taky pochopitelně nelíbí.

Úplně super by bylo, kdyby se mnohem víc soustředili na systemd jako na čistý init. Jako init je systemd podle mě dost dobrý a líbí se mi. Některé ostatní komponenty jako timesyncd nebo networkd se mi taky líbí a minimálně timesyncd používám, networkd aktuálně ne, ale asi na něj přejdu (nepotřebuju NetworkManager pro jedno LAN připojení, že).

CO mě ale sere, je, že oni ty komponenty rvou do jednoho build tree a dá se to vypnout jen v buildu přepínačem. Měli by to komponenty mnohem více oddělit, do samostatných repozitářů a následně balíků pro distra.

Třeba systemd-boot už mi přijdi jak technicky, politicky i morálně za hranou. Nevidím jediný plusový bod na inkluzi bootloaderu do systemd infrastruktury a cpát do do systemd balíku.

[kralyk z abclinuxu]

+1. Tesat.

[little.owl]

CO mě ale sere, je, že oni ty komponenty rvou do jednoho build tree a dá se to vypnout jen v buildu přepínačem. Měli by to komponenty mnohem více oddělit, do samostatných repozitářů a následně balíků pro distra

Unix tradicne byl a soucasne BSD jsou vyvijena v jednom repositari a bylo to vzdy prezentovana jako vyhoda, zejmena kvuli integraci. Jak je to zabalene do balicku je zalezitost konkretni distribuce, nemusi byt vse v jednom instalacnim balicku.

Třeba systemd-boot už mi přijdi jak technicky, politicky i morálně za hranou. Nevidím jediný plusový bod na inkluzi bootloaderu do systemd infrastruktury a cpát do do systemd balíku.

Proc? Je to volitelna komponenta, jednoduchy a rychly bootloder podporujici EFI secure boot a lze ho nahradit, pro kontejnery idealni. Gummiboot (systemd-boot) misto Grub2 kdykoliv to jde.

[xm]

Tak až bude gummiboot umět šifrovanou boot partition, dejte vědět. GRUB2 nemá konkurenci, jediné co mu chybí je integrace s TPM (existuje sice fork TrustedGRUB2, ale ten zas neumí EFI :-/).

[skunkOS]

Jo, ale to není argument, kterej by mi jasně řekl, proč to teda mesí bejt všechno součást jednoho build tree, když jde o projekt s úplně jinou funkcí než zbytek systemd (init).

[j]

Problem je predevsim v tom, ze ti to pod rukama prestane delat veci, kery ti doted 30let fugovaly, protoze ponovu to prece nikdo takhle nepotrebuje, protoze nejvyssi a nejchytrejsi se tak rozhod. Logy sou prece taky knicemu, takze to ze ti zmizej je vporadku.

[kralyk z abclinuxu]

A už sis zjistil, že systemd funguje na architekurách jiných než x86, nebo jsi na tom stále ještě zaseklý?

[j]

Narozdil od tene vim ze to nefunguje na naprosto zadne architekture, takze je uplne jedno kam se to snazis nacpat.

[kralyk z abclinuxu]

problém je spíše v tom, že ó náš nejvyšší a nejchytřejší začne tyto věci nejdříve silně doporučovat a posléze ostatní silně komplikovat, že na to postupně přejdeš ať chceš nebo nechceš.

Není tohle chyba spíše RedHatu než Ó Nejvyššího? To mě vždycky na těhle diskusích zaráží, když se začně nadávat na Lennarta. Mně přijde, že Lennart jako takovej a jeho názory jsou celkem irelevantní, není na místě spíš být znepokojen tím, že jedna firma umožní jednomu člověku ovlivňovat ekosystém tímhle způsobem? (Ať už je ten jeden člověk kdokoli.)

Bude to pravděpodobně završeno systemd-system.dat a k němu cli nebo gui systemd-regedit.

Pokud vim, Gnome má regedit už dlouhá léta.

[Sten]

systemd-mount nenahrazuje mount, ale generuje unity při připojení zařízení (v Udev), které (po vyřešení závislostí) spustí GNU mount.

[Nobody]

Tak to je snad jeste horsi, nez kdyby ho nahradil, protoze zbytecnejsi nez novy mount uz je fakt jenom wrapper kolem mountu.

[Conscript89]

treba udisks?

[Tomáš Bžatek]

udisks fakt neni jen wrapper kolem mountu, ale spis storage volume discovery a jakasi convenient knihovna pro GUI, aby se stejny kod nepsal tisickrat (udev enumerace, eventy, luks, mdraid, smart atd.).

[mirec]

Pekná teória, ale v praxi to aj tak každý píše 1000x. Udev dokáže pripojiť niektoré zariadenia, ale napríklad MTP, ktorý má mnoho spoločných vlastností (dá sa mountovať cez fuse, má dostupné určité metadáta ...) vôbec nerieši, takže pripojenie ďalších zariadení si aj tak píše každé prostredie posvojom.

[Tomáš Bžatek]

Michas dve veci dohromady. Udisks je lokalni storage management, neimplementuje filesystemy, ani sitove ci jine userspace protokoly, na to jsou jine projekty na jine urovni, casto jako nadstavba ve spolupraci s udisks.

A pokud se nekdo rozhodne reimplementovat existujici funkcionalitu jen kvuli nesympatiim k pouzitym knihovnam nebo jazyku, je to jeho problem

[mirec]

Aké knižnice sú k dispozícii? Pred pár mesiacmi som písal podporu udisks2 do prostredia a zistil som, že to nepripojí androidy, kameru a mnoho ďalších zariadení.

[Conscript89]

Omlouvam se, uznavam ze mi to trosku ujelo. Ono z uzivatelskeho hlediska to tak muze vypadat jako jakysi wrapper, ale "jen wrapper" to rozhodne neni.

[Sten]

To není wrapper kolem mountu, ale generátor unit pro systemd, podobně jako má systemd generátor třeba z fstab. Smyslem je, aby na mounty z Udev šlo pověsit závislosti jiných jednotek, třeba že se vám po připojení falsh disku automaticky spustí synchronizace.

[pc2005]

Aha, já to bral podle intuitivního jména. Proč je to orientovaný jen na mount v udevu, jsem myslel, že udev může spouštět skripty i při zasunutí třeba usb→uart adaptéru.

[Conscript89]

Muze, jednou jsem si script spousteny udevem (pri vlozeni flashky) napsal a zjistil ze trva moc dlouho (slo o kopirovani obsahu) a musel z nej udelat systemd unitu ktera je udevem spoustena. Ono scripty spoustet sice jde, ale ty scripty nesmi trvat moc dlouho, uz nevim proc to tak je.

[pc2005]

Ono scripty spoustet sice jde, ale ty scripty nesmi trvat moc dlouho

Aha tak to je zajímavá informace.

[Michal Kubeček]

Ono scripty spoustet sice jde, ale ty scripty nesmi trvat moc dlouho, uz nevim proc to tak je.

Protože udev na ten skript čeká a dokud neskončí, nepokračuje ve zpracování dalších pravidel ani dalších eventů.

[Sten]

Ok, nebylo to úplně přesně popsané. Místo aby Udev to zařízení připojil, vygeneruje mount unit v systemd, která spustí závislosti a mimo jiné to zařízení ve vhodný okamžik připojí (např. s parametry a po jednotkách, které uvedete v drop-inech). Udev může spouštět obecně jakékoliv skripty (pokud do určité doby skončí, Udev neumí závislosti, a tak nedělá paralelizaci), tohle slouží pro snazší integraci s ostatními jednotkami systemd. Systemd nemá jednotky pro obecný hardware, tak to je jen pro mountpointy.

[pc2005]

Ale dá se do budoucna předpokládat, že bude tlak na to, aby i ostatní eventy z udevu šly zapojit do toho závislostního chainu v systemd ne?

[little.owl]

Vy jste se nenamahal kouknout se do manualovych stranek, ze?

[Bedňa]

A už vie nabootovať systemd s pripojeným Ubuntu telefónom, alebo stále ostane v nekonečnej slučke?

Paródia pokračuje a pribúdajú stále nové diely. To by chcelo exporty priamo na YouTube (systemd-youtube).

[Marián Kyral]

Už jedou?

[pepe_]

bulanci.systemd ?

[Michal Navratil]

A co pridat grafickeho spravce bezicich demonu systemd-oom?

[Michal2]

Uz si to samo sebe zacina uvedomovat?

[nyan]

Tahle featura bude az ve verzi 666

[Heron]

"machinectl list" now shows the IP address of running containers in the output, as well as OS release information.

Užitečné.

systemctl gained a new --wait option

Mohli by přidat něco podobného i k machinectl. Příkaz machinectl stop skončí okamžitě, ale kontejner se vypíná déle. Chtělo by to nějaký parametr pro čekání na úplné vypnutí.

Support for dynamically creating users for the lifetime of a service has been added.

K čemu je to dobré? Pokud provozuju nějakou službu, pravděpodobně má i data na fs a ta by měla mít vlastníka jako uživatele té služby. Služby bez dat existují také, ale stále nevidím důvod, proč nevytvořit prostě klasického uživatele. Vždyť je to jen jeden řádek v /etc/passwd.

Možná je to jen rozšíření toho, co už dělá nspawn - ten si přemapuje uid ve kontejneru na úplně jiné uid v hostitelském os.

/etc/resolv.conf will be bind-mounted into containers started by systemd-nspawn, if possible, so any changes to resolv.conf contents are automatically propagated to the container.

WTF? No, další funkce k vypnutí. Tohle bude dělat jen problémy, protože při změně /etc/resolv.conf na jednom stroji asi nikdo nepředpokládá, že se mu to změní na desítkách dalších. Budou vznikat krásné nové chyby.

[trekker.dk]

Když vidím ty changelogy a postupné přidávání věcí k vypnutí, tak už se moc těším na přechod z Debianu Jessie na Stretch.

[MP]

U toho uzivatele, kdyz to vezmu z pohledu hostingu, tak mit neustale prepisovany /etc/passwd virtualnima uzivatelema a tim i treba neustale zmeny ve verzovacim systemu asi neni to prave orechove, misto pouzivani virtualnich...

[trekker.dk]

Z pohledu hostingu mi naopak přijde jako dobrý nápad mít jednotlivé uživatele oddělené na úrovni systémových uid, aby si nemohli hrabat do dat.

[Heron]

U toho uzivatele, kdyz to vezmu z pohledu hostingu, tak mit neustale prepisovany /etc/passwd virtualnima uzivatelema a tim i treba neustale zmeny ve verzovacim systemu asi neni to prave orechove, misto pouzivani virtualnich...

A proč by se to mělo neustále přepisovat? To neustále provozujete zcela jiné služby než před chvílí? Ptám se, zajímá mě k čemu to v praxi je.

V naší praxi, během vývoje softu se doiteruje do nějaké množiny služeb, které se potom nasadí do produkce. Potom se to mění pouze minimálně, služby se přidávají při nějakých updatech. Ale není to neustále a s časem těch změn postupně ubývá, tak jak soft zraje k nějakému optimálnímu stavu.

[little.owl]

Mohli by přidat něco podobného i k machinectl.

+1

Služby bez dat existují také, ale stále nevidím důvod, proč nevytvořit prostě klasického uživatele. Vždyť je to jen jeden řádek v /etc/passwd.

Hadam, ze je to soucast portable services. Proc by se mel plevelit passwd, pokud sluzba nemuze modifikovat jakykoliv FS a ma docasnou existenci?

Tohle bude dělat jen problémy, protože při změně /etc/resolv.conf na jednom stroji asi nikdo nepředpokládá, že se mu to změní na desítkách dalších. Budou vznikat krásné nové chyby.

Podle vas je lepsi nemit moznost zadne propagace a muset to pripadne menit na desitkach kontaineru?

[Heron]

Hadam, ze je to soucast portable services. Proc by se mel plevelit passwd, pokud sluzba nemuze modifikovat jakykoliv FS a ma docasnou existenci?

Moc nerozumím výrazu "plevelit". Pokud toho uživatele potřebuju, tak to není plevelení, pokud ho nepotřebuju, tak ho tam nemám. Ale já toto chápu jako zobecnění abstrakce, která už je v nspawnu, kterej si přemapovává uid, takže toto mi až tak nevadí. Spíše mě zajímá nějaký konkrétní případ z praxe, kdy se to hodí.

Podle vas je lepsi nemit moznost zadne propagace a muset to pripadne menit na desitkach kontaineru?

Já dávám přednost explicitním metodám před "ono se to nějak samo". Takže pokud někdo potřebuje měnit desítky kontejnerů, tak má použít něco jako ansible, puppet apod. systémy pro hromadnou správu. Stejně je bude muset mít pro konfiguraci jiných věcí, které nspawn (zatím) automaticky nebinduje. Nehledě na to, že stejně mám z hostitele přístup do fs těch kontejnerů, takže to můžu udělat i čistě souborovou operací (u kontejnerů nad adresářem nebo subvolume, u image to bude složitější). A také asi vždycky nechci mít v kontejnerech stejný resolv.conf, jako v hostiteli. A asi nechci mít ani stejný resolv.conf ve všech kontejnerech.

Druhá věc, virtualizace má (podle mě) sloužit spíše k izolaci než ke sjednocení. Kdybych chtěl ty aplikace nějak vzájemně propojovat a jedna druhou ovlivňovat, tak je nebudu virtualizovat, ale nechám je rovnou na jednom hostu. Virtualizaci používám pro zvýšení izolace.

[little.owl]

Pokud toho uživatele potřebuju, tak to není plevelení, pokud ho nepotřebuju, tak ho tam nemám.

A pokud ho potrebujete docasne pro beh nejake sluzby?

Já dávám přednost explicitním metodám před "ono se to nějak samo".

Ale to prece neni problem v danem pripade, chovani a propagace jsou explicitni a dokumentovane.

tak má použít něco jako ansible, puppet apod. systémy pro hromadnou správu.

To muze byt overkill a nemyslim, ze se tomu systemd snazi konkurovat.

Virtualizaci používám pro zvýšení izolace.

Mira izolace se muze lisit.

Pokud chcete rozumnet jeho motivaci, poslechnete si prednasku LP zde, zejmena druhou cast. Hadam, ze s tim muze byt uspesny, nebot se prida jednoduchy unifikovany zpusob jak distribuovat a konfigurovat sluzby; cas ukaze.

[Lol Phirae]

Pokud chcete rozumnet jeho motivaci, poslechnete si prednasku LP zde, zejmena druhou cast.

To je snad materiál tak pro psychiatry.

[Heron]

A pokud ho potrebujete docasne pro beh nejake sluzby?

Opět, co to je dočasná služba? Pochopitelně se stává, že se nainstaluje nějaký balík, o kterém se za týden zjistí, že není tak úplně potřeba, tak se zase odstraní. Mě vůbec nevadí, že týden běžela služba a že měla svého uživatele. Naopak mi to přijde úplně normální.

Ale to prece neni problem v danem pripade, chovani a propagace jsou explicitni a dokumentovane.

A ta dokumentace roste kde? Na www.freedesktop.org/software/systemd/man je sice index 232, ale man stránky nspawnu jsou 231. Hledal jsem v gitu, aktuální man nspawn a man resolv*, ale tam to též není.

Hlavně jde o to, že je to opět další změna chování. Admin nepředpokládá, že když změní resolv.conf někde (třeba zrovna na hostu s kontejnery - proč by se tento měl chovat jinak než ostatní?), že se to přepíše do nějakých dalších strojů. V předchozích verzích se mu to nestávalo.

Pokud chcete rozumnet jeho motivaci, poslechnete si prednasku LP zde, zejmena druhou cast. Hadam, ze s tim muze byt uspesny, nebot se prida jednoduchy unifikovany zpusob jak distribuovat a konfigurovat sluzby; cas ukaze.

No někde kolem 50 minuty říká, že bude možné distribuovat služby pomocí jednoho file image (a někde dřív: nebudou si vymýšlet vlastní, stačí jim, když to pozná kernel - squashfs, gpt image, adresář apod.). No já bych řekl, že jeden image pro distribuci software zde už existuje a říká se mu balíček pro balíčkovací systém distribuce.

A 50:47 tomu už jen nasazuje korunu:

systemctl start https://.../myservice.spi
systemctl status myservice

No, asi je to pořád lepší jak čím dál tím víc propagované:

curl http://.... | bash

nebo ještě lépe sudo bash

U portable services to alespoň poběží v nějaké izolaci. Ale že by se mi zrovna toto líbilo, tak to ne.

[Acci]

A 50:47 tomu už jen nasazuje korunu

Docker znáš?

[Heron]

Ano, z doslechu, tomu hype se nedalo uniknout.

[Acci]

Tak tam to funguje úplně stejně, jen ten repozitář pro image je centralizovaný, ale každý si tam může nahrát co chce.

[little.owl]

Opět, co to je dočasná služba? Pochopitelně se stává, že se nainstaluje nějaký balík, o kterém se za týden zjistí, že není tak úplně potřeba, tak se zase odstraní.

Koncept, kdy snadno instalujete sandboxovanou sluzbu a muzete ji odinstalovat bez jakychkoliv vedlejsich efektu na system na kterym bezi, ma smysl. Zatim mi prijde, ze se na zaklade svych pocitu a preferenci, uziti v limitovanem poctu scenaru, se snazite poukazovat, ze to neni potreba. Stale nechapu v cem vidite problem, pokud to nechcete, nepouzivejte to.

U nas behem CI padaji z buildserveru vyvojove snapshoty, ktery jsou distribuovany a spousten na systemech s volnou kapacitou, pricemz testovaci zivotnost vyvojoveho snapshotu muze byt treba od peti minut do dvou dnu, nez je po dobehnuti nahrazen novejsi verzi. Moznost snadno spoustet (instalovat) sandboxovane aplikace (service) bez efektu na hostitelsky system je v podstate co potrebujem, vedle snadne distribuce na stroje s volnou kapacitou.

No já bych řekl, že jeden image pro distribuci software zde už existuje a říká se mu balíček pro balíčkovací systém distribuce.

Fajn a v cem je problem? Pripojim NFS adresar, spustim sandboxovanou sluzbu, kdyz neni potreba ukoncim, odpojim adresar, a mam stale cisty system bez nutnosti neco lokalne instalovat.

A 50:47 tomu už jen nasazuje korunu:

systemctl start https://.../myservice.spi systemctl status myservice

V cem je problem?

A ta dokumentace roste kde? Na www.freedesktop.org/software/systemd/man je sice index 232, ale man stránky nspawnu jsou 231.

OK, dokumentace neni asi jeste aktualizovana. Changelog to ale popisuje pomerne jasne:

/etc/resolv.conf will be bind-mounted into containers started by systemd-nspawn, if possible, so any changes to resolv.conf contents are automatically propagated to the container.

[Heron]

odinstalovat bez jakychkoliv vedlejsich efektu

No já nevím jak kde, ale balíček snad lze odinstalovat bez vedlejších efektů. Install / purge dělám běžně.

Jinak jak jsem psal, mě toto až tak nevadí, chápu to jako rozšíření již existující abstrakce.

stale cisty system bez nutnosti neco lokalne instalovat.

Tohle je ve vašem komentáři potřetí. Jakou distribuci používáte, že instalace a odinstalace balíčku "plevelí" systém?

OK, dokumentace neni asi jeste aktualizovana. Changelog to ale popisuje pomerne jasne:

/etc/resolv.conf will be bind-mounted into containers started by systemd-nspawn, if possible, so any changes to resolv.conf contents are automatically propagated to the container.

Poměrně jasně "if possible"? Co to znamená? Pokud soubor půjde přepsat? Já bych to potřeboval znát poněkud přesněji, protože pokud "if possible" znamená "kdykoliv je to možné" (což je pro nspawn vždy), tak to je pro mě s nspawnem stopka.

[little.owl]

Tohle je ve vašem komentáři potřetí. Jakou distribuci používáte, že instalace a odinstalace balíčku "plevelí" systém?

Viz u meho profilu. Ale asi kazda rozumna, pokud instalace sluzby vytvari uzivatele a skupinu pod kterymi bezi.

Poměrně jasně "if possible"? Co to znamená? Pokud soubor půjde přepsat? Já bych to potřeboval znát poněkud přesněji, protože pokud "if possible" znamená "kdykoliv je to možné" (což je pro nspawn vždy), tak to je pro mě s nspawnem stopka.

Podle kodu, pokud jsem neco neprehledl (jsem utahan), se to pokusi nastavit vzdy pokud neni pouzit alespon jeden z parametru:

--network-zone
--network-bridge
--network-veth-extra
--network-veth
--network-ipvlan
--network-macvlan
--network-interface
--private-network

Pokud neni, pokusi se pouzit hostitelsky /usr/lib/systemd/resolv.conf (staticky soubor od systemd-resolved) nebo /etc/resolv.conf, pokud k nemu ma pristupova prava.

[Heron]

Viz u meho profilu. Ale asi kazda rozumna, pokud instalace sluzby vytvari uzivatele a skupinu pod kterymi bezi.

No distra, se kterými mám největší zkušenost, tak při odstranění balíčku uživatele a skupinu zase odstraní. Ale Lennart říkal, že Fedora uživatele nechává. No nevím, psát funkci k vůli stavu v jedno distru.

Podle kodu, pokud jsem neco neprehledl (jsem utahan), se to pokusi nastavit vzdy pokud neni pouzit alespon jeden z parametru:

Díky. Tohle dává smysl. Bez těchto parametrů není oddělené síťování, sdílí se IP s hostitelem a tak dává smysl i používat stejný resolv.conf. Tak to je ok.

[little.owl]

No distra, se kterými mám největší zkušenost, tak při odstranění balíčku uživatele a skupinu zase odstraní.

A jak se resi soubory vytvorene pod uzivatelem a skupinou, ktere mohou byt zavisle na konfiguraci, uziti? Purge AFAIK odstrani jen konfiguracni soubory, to znamena ze system muze byt ve stavu, kdy na disku jsou nemapovane UID/GID. Takze pristup, ktery pouziva Fedora, kdy takove uzivatele neodebira, ma smysl.

[kralyk z abclinuxu]

Purge AFAIK odstrani jen konfiguracni soubory, to znamena ze system muze byt ve stavu, kdy na disku jsou nemapovane UID/GID.

A v čem je problém?

[little.owl]

Security. Viz. treba z Fedora/Packaging/UsersAndGroups:

There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do with them?) and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID.

Fedora/CentOS/RHEL/openSuse/SLES, proste rozumnejsi distribuce to tak delaji .

[Heron]

Začínám litovat, že jsem se vůbec ptal.

Fedora/CentOS/RHEL/openSuse/SLES, proste rozumnejsi distribuce to tak delaji .

Ok no, jiné distribuce při odinstalaci balíčku upozorní, že adresář s daty je neprázdný, že jej nebude mazat a že si to má admin zařídit sám.

Fedora se vydala jinou cestou. V pohodě.

Čemu konkrétně teda vadí, že tam ten uživatel zůstane, když sám píšete, že rozumnější distribuce to tak dělají? Proč se tedy neřídíte pokyny té distribuce a toho uživatele tam rovnou nenecháte?

[pc2005]

Možná je to jen rozšíření toho, co už dělá nspawn - ten si přemapuje uid ve kontejneru na úplně jiné uid v hostitelském os.

UID maškaráda :-O .

[Michal Kubeček]

user namespace

[xm]

Jojo, největší zdroj attack vectorů na kernel v posledních letech Tedy místo aby USERNS zlepšil izlolaci, tak naopak přinesl celou řadu problémů a exploitů. Pokud vím je i nějaká sázka jak dlouho vydrží kernel bez nové USERNS zranitelnosti. Rozumné distribuce (jako třeba Arch Linux) USERNS zakazují

[Michal Kubeček]

Ty bezpečnostní chyby tam v mnoha případech byly "odjakživa", jen dlouhá léta nikoho nezajímaly, protože je mohl zneužít jen root, který to neměl zapotřebí. Pěkný příklad je třeba CVE-2016-4997/CVE-2016-4998. Zrovna včera přišla další taková; ta tam sice asi není moc dlouho (je to v poměrně novém driveru), ale taky je z kategorie, že by to bez userns bylo celkem nezajímavé.

[Michal Kubeček]

Hm, tak ne, driver se objevil už ve 2.6.16 - a mám temné podezření, že bug tam byl hned od začátku.

[xm]

No o to právě jde, USERNS prostě odkrývá gigantický attack surface. Jasně, lze na to koukat i tak, že tím přispívá k hledání chyb v kernelu Ale já bych tohle celkem oželel, pokud to znamená, že ještě dlouhá léta se kvůli němu budou objevovat stále nové a nové zranitelnosti, které by bez USERNS nebyly jinak exploitovatelné.