Vlákno názorů k článku
Projekt systemd-homed se chystá úplně překopat správu uživatelských účtů
od Miroslav Šilhavý - Asi se to pravověrným unixářům líbit nebude, ale...
-
Mno musím přiznat, že se mi starší nápad se soubory v /etc/users.d líbil více. Vidím tři potenciální problémy s .json souborem v domovském adresáři:
- identifikace domovského adresáře (/home se nepoužívá všude..)
- možnost ten soubor smazat (protože uživatel musí mít právo zápisu do "/home/user/." a nic více nepotřebuje)
- kolizi v případě použití /home z více různých strojů (NFS, více OS v grubu nebo třeba jen záloha a recovery pomocí jiného počítače)Přednášku jsem ještě neviděl, takže pokud má na toto řešení, tak super. Na /etc/passwd totiž rozhodně netrvám. Jsou s tím v distribucích jenom potíže (jak si služba správně přidá svůj systémový účet během instalace?).
-
Utilita useradd nevyřeší konflikt uid. Také neumí zjistit, kdo daného uživatele přidal a po odinstalaci balíku ho zase spolehlivě odstranit. Každá distribuce na to má nějaká makra, ale neexistuje nic unifikovaného.
Navíc soubor /etc/user.d/jarda dodržuje pravidlo, že vše je soubor, o dost více než řádek v /etc/passwd. Ten navíc nemusí zmizet, ale klidně ho může systém generovat.
Všimněte si kolik konfigurace v /etc je dnes řešeno pomocí sluzba.d adresářů. Ono to totiž má spoustu výhod.
A poslední otázka bezpředmětná není. Stačí taková věc jako přeinstalace systému se zachování /home. Jak se má instalátor nového systému k tomu .json souboru zachovat? Podpis neověří, ale přepsat by ho také nemusel, protože neví, jestli je potřebný nebo ne.
-
Administrace Linuxu tak jsme ji znali jednoduse konci. Vsechno se ted automatizije a "*.d" adresare automatizaci vyrazne zjednodusuji. Potteringovi - jak se zda - ale vadi cely adresar /etc. Nejde jen o /etc/passwd ale i o resolv.conf fstab a dalsi konfiguracni soubory.
Cele se to posunuje k tomu, ze /etc/ bude "read-only" a skutecna konfigurace bude v pameti procesu a vytvori se behem bootu. To je mozna dobre pro male ARM krabicky, ale pro lidi, kteri leta administrovali servery je to tezko prijatelna predstava.
-
Naopak, myslím, že je velmi předmětná. Jak aplikace, naprogramovaná např. v C++, Pythonu nebo Rustu, vytvoří nebo zničí uživatelský účet? Nijak, protože na to neexistuje API. Argumenty o utilitách a skriptech jsou mimo podstatu věci. Tady nejde o to, jak snadno nebo složitě si to nějaký sysadmin naskriptuje, ale o to, jak vývojář třetí strany zajistí, aby potřebná operace proběhla na stroji cílového uživatele, kde žádný admin není, uživatel nemá nejmenší úmysl se jím stát, počítač má na to, aby na něm psal knihu (nikoliv unixové skripty) a očekává, že věci budou Prostě Fungovat(tm) ve sto procentech případů a jedním klikem, stejně, jako to je na Windows nebo na macu.
-
Možná jsem narazili na podstatu ....
Aplikace nemá mít šanci vytvořit nebo zničit uživatelský účet.
Tu šanci má mít jen ten kdo má právo instalovat a ten použije např. " id xyz || useradd -system xyz" ať již ručně nebo v install scriptu aplikace.
Aplikace instalované uživatelem mají běhat v kontaineru a nemají do systému co sahat.
-
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,shadow,group,gshadow... 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čí.
-
L.Stříbrný podporovatel
> věci budou Prostě Fungovat(tm) ve sto procentech případů a jedním klikem, stejně, jako to je na Windows nebo na macu.
:-D :-D :-D :-D :-D
Tak ten byl dobrej.
-
S tou identifikací adresáře nevím, asi zo prostě povinně musí být v /home. Upřímně řečeno, nevím, proč by někdo bazíroval na tom, že se to ausgerechnet musí jmenovat jinak.
Pokud jde o ty adresáře z různých zdrojů, podíval jsem se na to video a mám pocit, ze je to naopak. Adresář není svázán s žádným konkrétním strojem, Poettering uvádí jako příklad, že je možné ho mít na flashce a jednoduše ji strčit do jakéhokoli počítače a bude to hned fungovat (samozřejmě s nastavitelnými bezpečnostními omezeními...). Ale nevím, nic z toho jsem nezkoušel, tak uvidíme.
-
Miroslav SuchýStříbrný podporovatelNejde o to, ze by se /home mohl jmenovat jinak, ale o to, ze v jeden cas muze mit franta home v /home/franta a ucet sluzby home ve /var/lib/sluzba/
-
Ano, přesně tak. To, co Windows mají už od dob NT, k tomu dochází Linux teď. Microsoft si to vyžral vrchovatě. Dodnes většina poloprofesionálů vůbec neumí ani s registry, ani s AD a GPO pracovat a jen na Windows nadávají. To samé se teď děje u Linuxu skrzevá systemd. Zavádějí se technologie, kterým už nebude každý rozumět na první pohled, ale bude se muset učit. Učení bolí, proto tolik povyku.
Linuxu teoreticky nic nebrání udržovat distribuce i s klasickým initem a PAM. Jenže v praxi vidíme, že dobrovolníci to nezachrání. Velcí kontributoři Linuxu (RedHat?) se rozhodli a díky penězům jim prostě komunita patří (financují si své lidi kteří jsou součástí komunity).
Za mě je to jednoznačně dobrý směr. Pokud se jednoduché Linuxové distribuce neudrží, stále tu máme celou rodinu BSD i dalších Unixů. Ale myslím, že to vůbec nebude potřeba. Na systemd-cokoliv si všichni (chtě nechtě) zvyknou a svět se bude točit dál.
-
Lennart se snaží splnit jiné zadání. Kiosky a stateless systém. Tvoří "home on a stick".
A o LDAP se nebojte, toho se RH nevzdá, protože ho chtějí zákaznici. Stejně tak kerberos. PAM je přimo v té přednášce zmíněný jako mechanizmus pro ten jeho nápad. V glibc taky asi nebudou určitě hned zahazovat podporu nsswitch.conf.
-
Filip JirsákStříbrný podporovatelDodnes většina poloprofesionálů vůbec neumí ani s registry, ani s AD a GPO pracovat a jen na Windows nadávají. To samé se teď děje u Linuxu skrzevá systemd. Zavádějí se technologie, kterým už nebude každý rozumět na první pohled, ale bude se muset učit.
Ono se pořád píše o těch technologiích, ale problém nejspíš vůbec nebude v nich. Požadavky na konfiguraci systémů a služeb už jsou tak různorodé a komplexní, že ta konfigurace je komplikovaná. A to je to, co dělá správcům problémy a co mají problém se naučit. Registry nebo AD jsou jen nástroj, jak tu konfiguraci spravovat. Teoreticky může být problém i v tom nástroji, ale spíš je to tak, že tyhle nástroje správu zjednodušují a pokud by se systém a služby konfigurovaly postaru, bylo to ještě podstatně komplikovanější. -
> zastarala podstata sama?
Jako že už neplatí?:
1. nástroj má dělat jednu věc a to pořádně
2. má být schopen přijímat data od ostatních nástrojů a také jim data předávat co nejjednodušeji (v "čitelné" formě ...)Jestli je to tak, tak byste to měl vysvětlit všem co se snaží obrovské molochoidní a neudržovatelné aplikace rozškubat do komponent/mikroservisů/... protože ti všichni jdou špatným směrem. A taky řekněte všem co poskytují otevřená data, že to dělají špatně, místo TXT/XML/JSON by měli data poskytovat v DBabc/JournaLFXNv.2.3/nebo jiném superformátu.
Sorry, ale málokdy se podaří, že by zesložitění za účelem zjednodušení fungovalo.
-
> 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...
-
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ší.
-
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.
-
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á.
-
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í.
-
Ondra Satai NekolaZlatý podporovatelZrovna 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.
-
Filip JirsákStříbrný podporovatel
Záleží na tom, co myslíte tou podstatou. Zda cíle, nebo prostředky, kterými jsou dosahovány. Protože jak se mění okolní svět, musíte měnit i prostředky, když chcete dojít ke stejnému cíli. Úplně stejně se muselo třeba na začátku dvacátého století řešit, co je podstatou dopravy – jestli je to kůň (prostředek), nebo jestli je to převezení něčeho někam (cíl). Protože k dosažení toho cíle začaly být vhodnější jiné prostředky.
-
tak to mam asi o 21. stoleti jinou predstavu, pane @silhavy. on ten @poettering asi bude docela chytry jedinec, ale je skoda, ze se neupnul na neco jineho, protoze prozatim mam pocit, ze na co v linux sahne, to rozbije a vzhledem k tomu, jak je urputny, tak zacinam mit strach, ze se mu podari podelat cely linuxovy ekosystem :-(
hlava mi nebere, jak na tohle mohla spousta distribuci naskocit. ze to udelal redhat me neprekvapuje, jejich distro s rpm jsem odepsal uz davno a pokazde, kdyz s nim prijdu do styku (pomerne casto), tak se v mem rozhodnuti jenom utvrdim, ale ze to udelal i debian, to me prekvapilo. diky bohu za gentoo.
to vam vsem, ktery systemd vychvalujete fakt nevadi binarni logy a naproste popreni toho, na cem unix stavi (command dela jen jednu vec, ale dela ji velmi dobre)? mne ten moloch (systemd) vazne desi a bojim se i tohoto noveho napadu s uzivateli...
-
to vam vsem, ktery systemd vychvalujete
Svět se nedělí na to, co vychvaluji a to, co zatracuji. Je možné docela obyčejně ocenit přínos něčeho, aniž bych z toho dělal existenční drama.
nevadi binarni logy
Binární logy jako takové mají svá plus a mínus. Osobně zrovna na tohle vyhraněný názor nemám a považuju to spíš za implementační detail.
naproste popreni toho, na cem unix stavi
To mi teda fakt nevadí, spíš si říkám, že už bylo dávno načase.
