Názory k článku
Projekt systemd-homed se chystá úplně překopat správu uživatelských účtů

PS: těch podpisů tam totiž samozřejmě může být víc.

Jenže součástí toho identity souboru jsou i oprávnění. A ta nemusí být stejná. Názvy systémových skupin se mezi systémy totiž dost často liší. Tohle je sice okrajový případ, ale ty ostatní potíže tam pořád jsou. Celý tento mechanizmus se dělá pro jeden konkrétní případ použití - kiosky.

Za A ten uživatelský účet je v tomto případě příklad, stejné je to se vším.

Za B, aplikace k tomu oprávněná samozřejmě musí být schopná vytvořit nebo zničit účet, od grafického rozhraní ve GNOME přes nějaký webový admin nástroj až po automatizovaný deployment v AWS atd.. K tomu je potřeba oficiální, dokumentované a předvídatelné API. Nějaký shellový guláš který čistě náhodou funguje u mne ale u nikoho jiného, protože někdo jiný to zase "na svém stroji chce takhle a ne onak" apod. to prostě neumožňuje.

@klokan 24.9.2019 9:04 [...] shellový guláš který čistě náhodou funguje u mne [...]

mozna varis shelove gulase, ale rec byla o standardnich terminalovych nastrojich, jestli je pouzije uzivatel v shellu, nebo tvurci GUI/PHP aplikace v GUI/PHP aplikaci je uz jedno, ty nastroje jsou dostupne v kazdem neoklestenem GNU/Linux, tedy slo/lze je bezproblemu pouzivat, nebo se da vytvorit API abys mel radost, ale muze pouzivat totozne configuracni soubory, neni kvuli tomu potreba aby se zahodilo zavedene /etc/passwd,sha­dow,group,gsha­dow... a znemoznilo pouzivani tech dostupnych nastroju a vseho co je do ted vyuzivalo...

Jenže mě jde o to, aby GNU/Linux byl nejlepší možný svobodný OS, ne o to, aby to nutně byl svobodný Unix. Soudě podle směru, kterým se mainstream vyvíjí, s touto představou nejsem sám, naopak to vypadá, že se kolem toho formuje konsensus. Na /etc/passwd, unixovém shellu a spol. není nic závazného a mimochodem ani Linus Torvalds za Linux, ani Richard Stallman za GNU nikdy nic takového netvrdili a nikomu neslibovali. Postupné nahrazování nejen initu, ale v důsledku prakticky celého základního userlandu novými komponentami kolem projektu systemd, fungujícími jinak, vyvíjenými s odlišným pojetím a filozofií, než Unix, není ani konspirace, ani "zrada" na nikom a na ničem, je to přirozený darwinovský vývoj tak, jak ve FOSS světě probíhal odjakživa. Mimochodem nemám ani akcie RedHatu, ani nejsem nějak zapojený do vývoje systemd, Poetteringa osobně neznám a na systemd jako takovém mi celkem nesejde, jde mi o směr a filozofii a tu dneska prosazuje systemd tak, jako to mohlo být něco jiného.

Ale všimni si prosím, že ještě dávno před systemd vznikl projekt Suckless, právě s cílem oponovat tomuto vývoji a razit unixovou údajnou filozofii. Jestli ho vůbec někdo doopravdy používá, tak je to celém světě pár jedinců. Uživatelská základna Debianu mezitím roste rychleji, než u Devuanu. Takže to asi o něčem svědčí.

tak datvat na plochu soubor ClickMe.png co obsahuje screen BSOD neni problem :-)

Expiraci hesel bych raději nepřipomínal. Čím hůře to půjde nastavit, tím lépe.

k čemu je dobrá expirace hesel mimo toho, že nutí uživatele používat slabá hesla (pokud si jej rovnou nenalepí na monitor)?

> k čemu je dobrá expirace hesel

To je diskusia mimo pointu. Pointa bola, ze /etc/passwd ako je teraz je *velmi* obmedzene a akakolvek extra funkcionalita sa musi dolepovat postrannymi subormi a konfiguraciami. Odtlacky prstov, yubikey.. Vsetko ma konfiguraciu niekde u seba a akakolvek pokrocilejsia konfiguracia uz v zasade /etc/passwd pouziva len na pridelenie UID. (aj aj to len preto lebo musi, UID ako take je dalsia z tych veci ktore su problematicke)

Přímo entelegentní je také model přístupových práv, kde právo vytvořit soubor v adresáři se rovná právo smazat kterýkoli jiný, ať už patří komukoliv. Samozřejmě, že místo, aby se to opravilo a zavedly se pořádné ACL (které uměl už MULTICS a které jsou výchozím modelem ve Windows), tak se implementoval rovnák pomocí dalších příznaků, ovládaných pochopitelně úplně jinak (chattr) a protože to má zase svoje úžasnosti, tak je ohýbák v podobě mount voleb, které ovšem pro jistotu většinou nejdou nastavit persistentně, atakdále...

Nechápu Vás, Windows je pravděpodobně systém který splňuje Vaše požadavky.
Tak proč se snažíte z Linuxu udělat špatný klon Windows?

Jak jste přišel na to, že Windows splňuje moje požadavky? Moje požadavky Windows nikdy nemůže splnit, protože není svobodný software. To neznamená, že bych měl nějaký zájem o to, aby svobodný OS, který používám, byl méně schopný a uživatelsky vyspělý, než Windows.

Právo zápisu do adresáře znamená právo upravovat seznam položek adresáře. Tj vytvářet a mazat. To je naprosto logické řešení základních přístupových práv.

O setfacl na pokročilá ACL jste už slyšel? Je s námi totiž už hodně let...

Je logické, že moci vytvořit soubor je totéž, co smazat soubor patřící někomu jinému? Tohle může tvrdit jenom někdo, kdo uvažuje tak, že správně je to, co dělá Unix, i když je to dementní.

O setfacl jsem samozřejmě "slyšel". Jejich implementace v Linuxu jednak tento problém neřeší, jednak je silně nepružná a nepraktická, a navíc se vztahuje jenom na soubory, nelze je používat na libovolný typ jaderného objektu. Ty tzv. NFS4 ACL, jaké má mj. i FreeBSD, jsou už lepší.

A proto mame i napr. sticky bit.

Ano, sám jsem se o něm přece ve svém příspěvku zmínil. Klasický příklad, jak Unix jednu hovadinu "řeší" další hovadinou. Správně by bylo moci udělit právo "smazat tento objekt", nastavitelné v ACL pro jednotlivé uživatele nebo skupiny. Jenže to by bylo čisté a koherentní řešení, takže místo toho nám unixoví filozofové vyprodukovali toto veledílo, které se dá nastavit jenom stylem "všechno nebo nic" a jak jinak, než úplně jiným způsobem než např. práva čtení nebo zápisu, pomocí jiného syscallu a s jinými datovými strukturami.

Jak se tedy má systém zachovat, pokud máte právo smazat adresář, ale ne jeho obsah? Buď neumožníte smazat nic, nebo necháte adresář v nekonzistentním stavu (část souborů pryč) nebo uděláte to co unix a řeknete, že si můžu smazat cokoliv v objektech, které vlastním.

On je pak totiž problém třeba s dohledáním souborů, které se náhodně vytvořily jinde (logy z procesů spuštěných jako root) nebo kvótami.

Systém se v tom případě má zachovat přesně tak, jak se chová už teď: dovolí smazat adresář jen tehdy, když je prázdný.

Což je pro uživatele něco pekelného. Tohle můžete možná udělat na produkčním serveru, ale desktop se takto chovat nesmí. Dovedete si představit jak se bude tvářit uživatel, až mu řeknete, že si nesmí smazat adresář ze svého vlastního /home? Obzvláště veselé to bude v případě, že tam zůstalo něco neviditelného...

FHS poměrně striktně odděluje systémová a uživatelská data. A v takové hierarchii dává to současné chování perfektní smysl, protože vlastníkem /home/uzivatel je uživatel a vlastníkem třeba /var/lib/uzivatel je systém. Root nemá co vytvářet soubory u uživatele v /home.

Pokud by Lennart chtěl, tak klidně může v /home udělat uzivatel.home (metadata) a uzivatel (data) s různými vlastníky. Ostatně o té .home variantě v té přednášce mluví.

Systém oprávnění není totiž izolovaná věc, souvisí i s tím jak se ten systém interně používá.

Tak zrovna v /home by to těžko mohl být problém. Uživatel vlastní všechny soubory a podadresáře a nevím, jak a kdy by došlo k tomu, že na některý z nich by uživatel neměl oprávnění smazat?

Co třeba Lennartem zmíněné .identity, které má obsahovat veškerá oprávnění a skupiny? Pokud takový soubor smažete, tak uživatel zmizí? O tom se tu totiž celou dobu bavíme.

Jinak při používání sudo se mi celkem často stane, že někde v /home zůstanou zbytky, které uživatel nevlastní.

1) Proč by to někdo mazal? Teoreticky omylem může, ale je to stejné riziko, jako že si omylem smaže celý home. Že se stávajícím systémem účet jako takový existuje v systému dál je plat prdné, když jednou zmizí všechna data. Pro uživatele totiž totiž mají cenu jeho dokumenty, ne jeho UID.

2) Pokud z toho máte obavy, dá se to celkem snadno řešit např. pomocí SELinuxu nebo AppArmoru

3) S tím, o čem jsme tady diskutovali výše, by to nebyl problém, na .identity by prostě nebylo nastavené právo smazání.

Zrovna sticky bit je přiklad, jak jeden bit zvládne udělat obrovský chlív. Jeden bit, dva naprosto odlišné koncepty použití (adresáře vs. soubory, u souborů to navíc nedává v 21. století smysl - o tom, že to vůbec nesouvisí s oprávněními nemluvě), nenavazuje dobře na zbytek systému práv. A co "unix", to jiné chování.

Ale hlavně že jedna věc, ale dobře.

@MartinX ale supluješ toho hastroše usilovně ;-)

Pokusme se na chvíli netrollovat a podívjme se na to trochu jinak, než je v těchto diskuzích obvyklé. Systemd není, nebyl a nebude jediná binárka. Ale představme si čistě teoreticky, že by byl, co by to znamenalo v praxi? Myslím si, že v podstatě vůbec nic.

Představme si tři binárky: funkceA, funkceB a funkceC. Jsme samozřejmě ve scénáři, že žádná z nich nemá nějaké zvláštní kapability, setuid root apod. Představme si dále, že by to místo toho někdo přepsal do jednoho programu, ve kterém by byly tři funkce funkceA(), funkceB() a funkceC() a dále main(), který by volal jednu nebo druhou, podle voleb. Z hlediska komplexity vývoje je to v podstatě jedno, každý si napíše svoji vlastní funkci, jediný reálný rozdíl je snad v tom, že některé potenciálně ošemetné věci (konfigurační parser, parser voleb na příkazové řádce, případný drop privilegií a další věci) se udělají jednou pro vždy v mainu, místo aby je každý musel dělat zvlášť a většinou blbě. Z hlediska bezpečnosti by případná zranitelnost v jedné z těch tří funkcí umožnila, např pomocí ROPu atd., volat i ty druhé dvě, ale úplně stejně může volat i ty ostatní binárky (ledaže by se používal seccomp, nějaký privátní kontejner atd., ale v praxi tomu tak téměř nikdy není, nemalou mírou i kvůli jekotu, že tyhle věci nejsou přenosné na BSD a/nebo nejsou tím pravým "unixovým" řešením - viděno na fórech Devuanu...).

Dále je možné se na to podívat tak, že je vlastně úplně jedno, jestli máme tři programy funkceA, funkceB a funkceC, nebo jeden program funkce, se závislostí na libfunkceA.so, libfunkceB.so a libfunkceC.so. I to jsou tři různé binárky, jenom způsob volání je jiný a tak nějak nevím, proč by na něm mělo vlastně záležet. V MULTICSu mimochodem neexistoval rozdíl mezi spustitelným programem a knihovnou a třeba by vůbec nebylo od věci se k tomuto principu vrátit.

A je tu ještě jeden možný náhled, co je vlastně binárka? Nic víc a nic míň, než speciální druh archivu. Je celkem snadné napsat filesystem ovladač (ať už v jádře nebo přes FUSE), aby šla jednotlivá binárka nebo knihovna namountovat a klidně pak vidět každou volatelnou funkci jako samostatnou "binárku". Jde jenom o to, na jakou úroveň si - v podstatě naprosto arbitrárně - nastavíme abstrakci. Z koncepčního hlediska se vlastně dá třeba i /dev/sda považovat za jednu gigantickou "binárku" a i když někdo bezpochyby okamžitě prohlásí, že to je blbost, takový ať si prosím alespoň všimne, že reálné rozdíly jsou vlastně jenom v implementačních detailech.

Problém neni ve formě uložení na disku, ale v závislostech. Pokud máte tři nezávislé funkce, tak prostě použijete jen tu, co se Vám líbí. Pokud vytvoříte tvrdou závislost (řekněme na systemd-logind), tak už tu volnost nemáte a je jedno jestli jsou to nezávislé binárky, funkce nebo dynamické knihovny.

Tak pokud instalujete např. balík coreutils, tak tam těch binárek máte požehnaně a rozhodně nemůžu tvrdit, že už jsem někdy (vědomě) použil všechny. Neboli stále je to jedno, prostě na disku je uložen kód, který třeba Vy osobně momentálně nepoužíváte (ale nevíte, jestli nějaká aplikace třetí strany ho náhodou nebude předpokládat) a nesejde na tom, v kterém konkrétním souboru se nachází. To na tom svém mnohaterabytovém disku máte nedostatek místa, nebo co? ;)

@MartinX

BusyBox jsi viděl? ;-)

Řeknu Vám něco, co Vás asi šokuje. Lidé používají počítače proto, aby provozovali aplikace, vydělávali peníze, bavili se multimédii a hrami, učili se atd. Nikdo si nejde koupit počítač za účelem splnit "základní filozofii Unixu". Je to sice na jinou debatu, ale jsem pevně přesvědčen, že ona Unixová "filozovie" je ostatně v základu špatná a škodlivá, maximálně má smysl v některých velmi (zdůrazňuji velmi) úzce definovaných případech.

Kromě toho ta takzvaná "Filozofie" není filozofií, protože nikdo si nikdy nesedl, aby popřemýšlel o tom, jak nejlépe navrhnout funkční a koherentní OS. Unix vznikl z 95% tak, že každý si sám zbastlil nějakou slátaninu, která s odřenýma ušima řešila jeho okamžitý problém, bez žádné celkové vize nebo zamyšlení, jak zapadá do většího celku. Proto máme cron, který neví a nemůže vědět o tom, jaké služby mají běžet, mail, který je tak "geniální", že nemá API a proto nelze normálně mít v aplikaci funkci "odeslat mailem" aniž by člověk musel ručně implementovat klienta SMTP a všechno ostatní, konfigurace textovými soubory, každý s naprosto jinou a nekompatibilní syntaxí, a ex post zavedou bezpečnostní díru jménem setuid, když nějakému Unixovému filozofovi došlo, že v Unixu nejde nastavit různa přístupová práva pro různé části souboru, a tak bych mohl pokračovat donekonečna.

A navíc ta údajná "filozofie" prostě vůbec není pravda. V Unixu neexistuje jediný program, který by dělal "jednu věc". Dokonce i taková trivialita, jako je /bin/false, musí kromě vlastní primární funkce obsahovat... parser (přejděme taktně mlčením to, že je vůbec potřeba, aby existovalo cosi jako /bin/false). A za druhé neexistuje jeden jediný unixový program, o kterém bych mohl s klidným svědomím říct, že něco dělá "well". I ten zmiňovaný /bin/false má historii exploitů, s lpr se táhnou nevyřešené race conditions už desítky let, vi (kromě toho, že nevím, co je tak "well" na tom, že k pohybu kurzoru nemůžu ve výchozím stavu normálně používat šipky kurzoru) je tak proslulý svými bugy, že jiné programy, které se ho snaží nahradit, je musí záměrně implementovat taky, atd atd atd. Děkuji, myslím, že bez toho celkem přežiju a díky za systemd, Lennarte.

V posledním bodě máte pravdu, Unixák asi dneska není typickým uživatelem Linuxu ani typickou cílovou skupinou, ale možná nezbývá, než si spolu s Járou Cimrmanem říct, že o tom můžeme vést spory, můžeme s tím nesouhlasit, ale to je tak všechno, to s tím můžeme dělat.

Pak věřím, že jste si sám taky doma sletoval základní desku, abyste nevypadal jako cvičená opice, která tomu "nerozumí". Ze stejného důvodu je samozřejmě vyloučené na ní používat jakýkoli integrovaný obvod. Jak jste daleko s tím vaším překladačem C? Přece jenom cvičené opice se naučí používat gcc aniž by "tomu rozuměly".

PS - berte to prosím s nadsázkou...

Pane Klokane, tu filosofii jste vubec ani trochu nepochopil. Pro vas pred par lety napsali webovy prohlizec. Prikazova radka vam do rukou nepatri.

Příkazovou řádku jsem používal pár desítek let a rád ji používám i dnes tam, kde mi něco přináší, místo, aby byla koulí u nohy. Z čeho jsem už trochu vyrostl, je hraní si na l33t unixáka, který nalézá potěšení v tom, že patlá zabugované skripty na věci, které v takovém Windows prostě fungují samy od sebe. Been there, done that, jak se říká, dneska očekávám, že počítač bude plnit roli, na kterou počítače primárně existují, totiž automatizaci nudných, nezajímavých ale časově náročných činností, počínaje správou samotného OS.

> A za druhé neexistuje jeden jediný unixový program, o kterém bych mohl s klidným svědomím říct, že něco dělá "well".

Není to tak trochu klamání? Copak systemd je "well"? Ba co víc, je systemd alespoň víc "well"? Ano, dá se mu přiznat jistá snaha o koncepčnost a deklarativní způsob zápisu já taky rád. Ale obávám se, že už navěky se zapíše do Linuxové historie jako odstrašující příklad "not-well" projektu.

Žádný netriviální program není dokonalý. Systemd je určitě lepší, než to, co nahrazuje: je deklarativní, vychází z principu "všechno je API" místo "všechno je skript nebo textový soubor", je z podstaty bezpečnější (samozřejmě, že taky může mít, a už měl, zranitelnosti), má relativně výbornou dokumentaci a pokud vývojáři dister, většina uživatelů nebo správci data center ve Facebooku a Googlu všichni svorně nelžou, tak celkem spolehlivě funguje. Když někdo neustále opakuje, jak je špatný, tak bych rád slyšel nějaký opravdický argument, nejen povinnou recitaci unixové údajné filozofie nebo "moudra" stylu systemd je jedna obrovská binárka, systemd je x86 only nebo systemd je zlo, protože odstranil problém, který se můj skript snažil blbě řešit a ten skript mi tím pádem už nefunguje.

24. 9. 2019, 09:58 editováno autorem komentáře

Někdo tady zřejmě má jednu obrovskou binárku systemd, tak já mám stejně tak megabinárku gnome, no :)