Klasický vývojářský problém - zneužívání jedné proměnné/konfigurace pro více významů. User má konfigurovat jen user name a UserID jen jeho ID. Každé automagické odhadování "co by to tak mohlo být" je cesta do pekel a hodí se tak někam do UI pro vyhledávání. Pro takto kritickou infrastrukturu je to překvapivé.
Ale vis jak, soudruh Poettering ti tu servisu proste spusti, at se deje co se deje, zejo ... takze bys mu za to mel vlastne dekovat no ne? Co natom ze misto pod pozadovanym userem ... trebas pod rootem. A kdyby nahodou neco kikslo cestou, tak ti to bude restartovat a restartovat a restartovat ... az ti to urestartuje k smrti.
BTW: Zrovna nedavno sem resil proc jedna appka padala a padala ... mno on soudruh tvurce byl asi ze stejny partaje, protoze na varchar poslal where x = 5 ... a ono tam bylo taky A, N, B ... a jaksi to padalo na tom, ze 5 != '5'.
S tímhle přístupem ("pokud to správně nefunguje, spustíme to jako root") si trošku zmýlil platformu; měl systemd vydat pro Windows ME, a ne pro linucha (a to proti woknům v podstatě nic nemám, je to nástroj stejně jako třeba krumpáč, a má svoje vlastnosti, silný i slabý stránky, na něco se hodí a na něco ne).
=====
1. neexistence předpisu pro rozlišení významů
=====
Nejlepší je významy nemuset rozlišovat vůbec, tj. z principu je nemíchat.
======
2. spouštění pod rootem v případě chyby
======
Argumentuje rádoby přísně logicky - pokud je hodnota jakéhokoliv nastavení validní, použije se, a když se ukáže jako nesprávná, hodí chybu (např. neexistující uživatel). Pokud je hodnota od začátku nevalidní (např. v jejich validátoru číslo na začátku uživatelského jména), jen to zaloguje warningem a nastavení ignoruje. Proto to ignoruje a spustí pod defaultní hodnotou = root.
Celý tenhle princip je IMO blbě. U tak kritických věcí by neměli nevalidní konfiguraci vůbec dovolit, akorát to vede na akceptování bordelu v konfigurácích.
Sloučení významů je špatně. Už tak jde o záznam převedený na string, kde není zaručeno nic. Rozsah proměnné, číselná soustava, int/floatt,... Jenom debil si to komplikuje tím, že jeden klíč může mít dva významy. Buďto chci UserName, nebo UserId a na 100% to ví jenom ten, kdo skript píše.
Neexistence předpisu na tom nic nezmění. Jenom by upozornila na další způsob eskalace privilegií, prostě přidání znaku do konfiguračního souboru. Což může udělat kdokoliv, kdo třeba spravuje balíček.
S tím, že něco by default spustí pod rootem, pokud neidentifikuje uživatele, to není chyba. To je diagnóza.
A to, že se "musí držet systémů se striktnějším zabezpečením" je přece další blbost. Přece pokud mám striktní pravidla jako podmnožinu benevolentních, musím vstup ošetřit tak, aby se korektně choval na benevolentních pravidlech. Že selže i něco jinýho je irelevantní, zvlášť v případě systémové komponenty. A tohle je ten případ - benevolentní systém podporuje něco navíc (číslo jako prví znak ve jméně) proti striktním.
To slučování bych neviděl tak jednoznačně, je to otázka pohledu. Zde se jedná o uvedení uživatele jakýmkoliv způsobem, v budoucnu to může být třeba jednodušeji rozšiřitelné. Když budete naopak používat userid i username, musíte zase řešit, zda nejsou údaje uvedeny zaráz.
Mimoto uvedená chyba dokonce ani nebyla způsobena sloučením významů, ale chybným zpracováním údaje, takže to tu protřepáváme zbytečně.
Jinak receno, dasli typicka ukazka tohodle kretena ... neco zkurvi, a chce po ostatnich at zmenej svuj sw ...
Fakt nevim proc by user nemoh zacinat cislem. Sem zvedat, kdy ten kokot napise systemd-mta ... a pak se bude rozcilvoat ze hacky v domene (nebo v dokonce v mailu) prece bejt nemuzou ...
Ono je víc programů, které s tím mají problém. Ten regexp (^[a-z][-a-z0-9]*$) v adduser není jen pro srandu.
Hlavní problém vidím v tom, že se to chová nekonzistentně. Toto se stane při spuštení unity s nastaveným neexistujícím uživatelem:
root@tomas:/etc/systemd/system# systemctl start t Job for t.service failed because the control process exited with error code. See "systemctl status t.service" and "journalctl -xe" for details. Jul 03 08:19:11 tomas systemd[2303]: t.service: Failed to determine user credentials: No such process Jul 03 08:19:11 tomas systemd[1]: t.service: Main process exited, code=exited, status=217/USER Jul 03 08:19:11 tomas systemd[1]: Failed to start Test. Jul 03 08:19:11 tomas systemd[1]: t.service: Unit entered failed state. Jul 03 08:19:11 tomas systemd[1]: t.service: Failed with result 'exit-code'.
Chyba, služba se nepustí a je to jasné už z řádky.
Toto se stane, pokud na počátek jména toho neexistujícího uživatele dám nulu:
Jul 03 08:18:35 tomas systemd[1]: Reloading. Jul 03 08:18:38 tomas systemd[1]: /etc/systemd/system/t.service:6: Invalid user/group name or numeric ID, ignoring: 0tomasxxx Jul 03 08:18:38 tomas systemd[1]: Starting Test... Jul 03 08:18:38 tomas echo[2281]: testing systemd Jul 03 08:18:38 tomas systemd[1]: Started Test.
Služba se spustí (pod rootem), na řádku není žádná chyba. V logu je ignoring.
Což je teda dost naprd.
Pěkná bezpečnostní díra, ale zatím to LP odmítá řešit (klasika). Uvidíme, jak to dopadne. Nejlepší by bylo, kdyby od toho projektu odešel a převzali jej rozumní správci, jako tomu bylo u pulseaudia. Tam hoši na pohodu komunikují s týmem alsy a obojí se posouvá kupředu. S LP se taky zpočátku štěkali. LP mívá dobré nápady, ale není vhodný člověk na správu/následný rozvoj a udržování.
Pořád mě překvapuje neschopnost manažerů Redhatu - to opravdu tak základní věc nevidí? I když asi korporátní klasika , firma na burze (majitel žádný), obraty (= bonusy) rostou, smrádek a teplíčko.
Víš co ňufíku? Nejdřív si zjisti jak to funguje a pak o tom mluv. Systémový unit file vyrobí jen člověk, co má oprávnění roota, nebo /etc/systems/systém/
Ten se spouští pod uživatelem definovaným v Unit file.
Uživatelské unit soubory (pokud tím uživatelem není root) se pochopitelně pod rootem spustit nedají.
Ale kdybys nebyl naprostý dutohlav, došlo by ti, že na tebou popisovanou bezpečnostní chybu by stačilo prostě napsat do usera root, nemusel bys blbnout s čísly.
A jak je to doopravdy??? viz. "Dle další diskuse problém pramení z toho, že pokud direktiva „User=…“ začíná číslem, parsuje se jako UID (tedy číselný identifikátor uživatele), a pokud nejde rozparsovat, celá direktiva se vyhodnotí jako neznámá a ignoruje se." - mně na to jeho definice sedí. Btw vzhledem k tomu, že ignoruje chybový stav tak souhlasím i s druhou "expresivnější" částí ....
Si to zkus:
Normálka:
[Service]
Type=oneshot
User=tomas
ExecStart=/usr/bin/id
Jul 03 09:47:37 raid systemd[1]: Starting t.service...
Jul 03 09:47:37 raid id[12961]: uid=1000(tomas) gid=1000(tomas) ...
Jul 03 09:47:37 raid systemd[1]: Started t.service.
Neexistujíci user:
[Service]
Type=oneshot
User=tomasxxx
ExecStart=/usr/bin/id
Jul 03 09:48:32 raid systemd[1]: Starting t.service...
Jul 03 09:48:32 raid systemd[13357]: t.service: Failed to determine user credentials: No such process
Jul 03 09:48:32 raid systemd[1]: t.service: Main process exited, code=exited, status=217/USER
Jul 03 09:48:32 raid systemd[1]: Failed to start t.service.
Jul 03 09:48:32 raid systemd[1]: t.service: Unit entered failed state.
Jul 03 09:48:32 raid systemd[1]: t.service: Failed with result 'exit-code'.
User s nulou na počátku:
[Service]
Type=oneshot
User=0tomasxxx
ExecStart=/usr/bin/id
Jul 03 09:49:10 raid systemd[1]: /etc/systemd/system/t.service:3: Invalid user/group name or numeric ID, ignoring: 0tomasxxx
Jul 03 09:49:12 raid systemd[1]: Starting t.service...
Jul 03 09:49:12 raid id[13681]: uid=0(root) gid=0(root) groups=0(root)
Jul 03 09:49:12 raid systemd[1]: Started t.service.
Položka User v unit souboru není povinná. Pokud není uvedena nebo má chybný formát a jde o systémový unit file, použije se uživatel root. (Kdyby to tak nebylo a User bylo povinné, budou si ti samí lidé stěžovat, že je to nesmysl, že je přece logické, že chci systémovou službu spouštět jako root.) To, že je nevalidní uživatelské jméno s nulou na začátku, je jen jeden z mnoha případů. Když jako uživatele zadáte třeba @"#!, bude to také vyhodnoceno jako syntakticky chybné uživatelské jméno a řádek bude ignorován. A systemd se chová tak, že pokud narazí na neznámou volbu nebo volbu s chybnou syntaxí, vypíše varování do logu a volbu ignoruje. To zajišťuje zpětnou kompatibilitu, protože jednotku s novou volbou nebo novým formátem volby spustíte i pod starším systemd. Jediným řešením by tedy bylo vybrat některé volby, a v jejich případě chybnou syntaxi nevyhodnocovat jako varování ale jako chybu. Jenže které volby byste do takového seznam u vybral a proč? Není lepší, když jsou pravidla pro všechny volby stejná?
Zkrátka se předpokládá, že správce systému má jednotky napsané správně. Když správce v jednotce uvede jiného uživatele, než chtěl, nebo jiný příkaz, taky se provede něco jiného, než správce zamýšlel.
Jaký má smysl u tak kritické komponenty poskytovat zpětnou kompatibilitu konfigurace na starší verzi systemd místo bezpečného chování - tedy nespuštění služby při nesprávné konfiguraci, o které systém jasně ví? Když např. v smb.conf uvedu blbost - konečná. V my.ini - to samé. Atd. IMO to tak je správně.
Systemd nevidí do hlavy správci, aby mohl rozpoznat každou nesprávnou konfiguraci. Nejde jen o zpětnou kompatibilitu se staršími verzemi systemd, jde i o kompatibilitu s jinými aplikacemi, které používají unit soubory. Při rozpoznání pravděpodobně nesprávné konfigurace vypíše varování do logu.
Tady se ukazuje rozdíl mezi správci, kteří po napsání jednotky otestují, zda funguje, a zkontrolují logy, a správci, které nějaké varování nezajímá a řeší až případ, kdy jim služba vůbec nenastartuje (a nejspíš je pak na to stejně musí upozornit někdo jiný).
To není proto, že jméno začíná nulou.
Ano, při kontrole logů může být pozdě, proto má správce jednotku napsat správně a spustit ji teprve po kontrole. Když do ExecStartPre zadá rm -r /*, tak mu to smaže celý systém. To je také chyba systemd?Když zadá Usr=nobody, spustí se jednotka pod rootem. Taky chyba systemd?
Sorry, ale samotný systemd s tebou nesouhlasí:
systemd[1]: /etc/systemd/system/t.service:3: Invalid user/group name or numeric ID, ignoring: 0tomasxxx
systemd[1]: /etc/systemd/system/t.service:5: Unknown lvalue 'Usr' in section 'Service'
Evidentně to dělá rozdíl mezi neznámou lvalue a mezi vadnou hodnotou známé lvalue.
Ano, oba řádky se to rozhodne ignorovat. To je asi to jediné, co mají společného. Pokud se do User dá jméno, které systemd považuje za validní, tak už to položku User neignoruje a začne se to podle ní řídit.
Což mimochodem taky znamená, že pokud v budoucnu se systemd změní a jméno "0tomasxxx" to bude považoval za validní uživatelské jméno, tak ta unita selže na neznámého uživatele. Unita, která do té doby "zpětně kompatibilně" fungovala.
Nechápu, jak tohle může někdo obhajovat.
Vždyť popisuješ přesně to, co jsem napsal. Neznámá volba nebo neznámý formát volby znamená varování do logu a přeskočení dané volby. Obojí je logické kvůli kompatibilitě s jinými programy. Teprve pokud je volba známá a má známý formát, systemd se ji pokusí zpracovat. V případě uživatelského jména tedy vyhledá uživatele s daným jménem – a pokud neexistuje, je to jednoznačně chyba, proto také systemd danou jednotku nespustí.
Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.
Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí. To, že je volba s neznámou syntaxí ignorována? Nebo obecně princip kompatibility formátu, kdy je ignorována neznámá volba nebo volba s neznámou syntaxí? Nebo ti to vadí jen u volby User a ta by se měla chovat jinak, než ostatní volby?
Já chápu, že to chování je na první pohled divné. Ale to zacházení s neznámými volbami a neznámými formáty voleb je logické, a je logické, že se systemd ke všem volbám chová stejně.
Jak souvisí kompatibilita s jinými programy s neznámým formátem známé volby? Protože o ten tu přece celou dobu jde - místo aby hodil chybu a skončil, nastavení ignoruje a místo něj použije default. A klidně by to mohlo fungovat stejně pro všechny známé volby - neumím zpracovat obsah - končím. Jako je to u jiných projektů.
Pokud nechápeš, jak to někdo může obhajovat, měl bys nejprve napsat, co ti vlastně vadí.
Pokud napíšu lvalue= tak očekávám:
* Pokud lvalue nezná, tak mě na to upozorní. Ocenil bych možnost, kdyby to nebylo jen upozornění, ale kdyby to s neznámým atributem vůbec nejelo (prostě tato unita nebude provedena, dokud jsou v ní chyby nebo neznámé atributy).
* Pokud lvalue zná, tak očekávám, že se to pokusí zpracovat hodnotu a pokud toto zpracování selže, unita nebude provedena a systemd ohlásí chybu (tak jak se děje, pokud dám do User neexistujícího uživatele).
Prostě tak jak se chovají jiné programy. Pokud jinému programu dám lvalue=nesmysl, tak typicky ani nenastartuje.
Pokud jinému programu dám neznámou lvalue, tak většina z nich mě na to upozorní (systemd taky, v logu).
Co ovšem nechci je to, aby chování záleželo syntaxe hodnot. Tady, syntax error znamená, že se to bude celé ignorovat. Tohle je chyba o které se tady diskutuje.
Pokud se systemd v budoucnosti změní, může se změnit různými způsoby. Číslice na začátku může být chápána jako prefix – podobně, jako např. spuštění příkazu může mít prefix +. A nebo by číslice na začátku mohla být považována za validní uživatelské jméno, teprve pak platilo to, co jsi napsal – že by jednotka při startu selhala, pokud by ten uživatel neexistoval.
Aha, takže máme bezpečnostní problém (spouštění unit za roota, pokud správce nastavil attibut User, považuji za vážný bezpečnostní problém), ale budeme ho ignorovat, protože větší výhodu má budoucí změna syntaxe.
Takhle se systémový software opravdu nepíše.
Ale asi je to fakt o těch správcích, jak jsi psal. Já mám rád software, který svou práci bere vážně. Kdysi jsem psal o jednom příběhu s MySQL, který se taky rozhodl ignorovat to, že innodb (po změně konfigu) nenajelo, ignorovalo to create table ... engine=innodb a vytvořilo to typ mysiam, ignorovalo to begin tranaction a rollack (myisam nepodporuje). Však co na tom, že někdo přišel o data, sere pes...
Jestli tímto způsobem autoři software přemýšlí (a u Lennarta na to máme důkazů už dost), tak je celkem dobré ten software nepoužívat. U normálního softu mě to na nestandardní konfiguraci upozorní. Pokud hodnota neodpovídá typu konfigurační volby, tak to nenajede. Apod. Je soft, kde to jeho autoři berou vážně. A potom je ten zbytek.
Oba požadavky znamenají, že syntaxe jednotkového souboru je striktně vázána na jednu verzi systemd. Předpokládám, že jednotkový soubor má ambici být univerzálním formátem, který budou používat i jiné nástroje spravující služby. Dovedu si třeba představit, že v jednotkovém souboru bude i popis toho, na kolika a jakých strojích v clusteru se má jednotka spustit.
To, že program ignoruje neznámé hodnoty, je běžná situace – zejména v případech, kdy nepoužívá formát souboru určený jenom pro daný program.
To, že se ignorují neznámé formáty (ty píšeš „syntax error“) je nedílná součást té otevřené definice formátu, která umožňuje budoucí úpravy. Třeba v HTML prohlížeče ignorují jak neznámé tagy (což by odpovídalo těm neznámým volbám), tak neznámé atributy na známém tagu (což by odpovídalo tomu neznámému formátu). Jenom díky tomu se HTML může vůbec vyvíjet – kdyby to tak nebylo, HTML už dávno zemřelo ve verzi 1.0.
Mně se ten formát jednotkových souborů vůbec nelíbí, ale když už byl zvolen takhle, zachází se s ním logicky, konzistentně, a je možné, aby se programy používající ten formát rozvíjely. Ostatně i samotné systemd už několikrát využilo toho, že přidalo nový formát volby.
Pokud správce nastavil User na neplatnou hodnotu a pokusí se to spustit, je to jeho chyba, ne bezpečnostní chyba systemd. root má milion způsobů, jak omylem něco spustit jako root – a musí si to pohlídat, od toho je root.
Systemd na nestandardní konfiguraci upozorňuje. Ale změnit to na tvrdou chybu by znamenalo úplně rezignovat na kompatibilitu formátu jednotkových souborů. Může se ti to nelíbit, třeba bys dal přednost formátu souboru svázaného s konkrétní verzí systemd (což by byl krok i proti modulárnosti systemd). Ale autoři systemd se rozhodli pro kompatibilní formát, což má tenhle důsledek. To ale neznamená, že to autoři systemd neberou vážně.
Citace Filipa Jirsaka: "Pokud správce nastavil User na neplatnou hodnotu a pokusí se to spustit, je to jeho chyba, ne bezpečnostní chyba systemd. root má milion způsobů, jak omylem něco spustit jako root – a musí si to pohlídat, od toho je root."
Nevazeny pokrytce FJ, asi jste uz zapomnel na nasi diskusi ohledne vynucenych windowsovskych aktualizaci, ktere jste tak nadsene obhajoval. Proc v pripade windows povazujete spravce systemu za natolik neschopneho, aby si sam rozhodoval o bezpecnostnich otazkach a o zodpovednost se podle vas musi postarat MS, zatimco v pripade unixu je podle vas vse zodpovednosti spravce a nikoho jineho. Nechci vam rozporovat ani jedno z toho, jen se vas chci zeptat, jak se sam sobe dokazete vylhat z nekonzistentnosti vaseho uvazovani.
Citace: "Vynucené automatické aktualizace Windows se týkají domácích Windows, které žádného správce nemají."
No to je slusna demagogie. Tenhle argument by se "jakz takz" dal uznat, pokud by se to tykalo pouze verze Home. Bezny uzivatel si proste verzi Professional neporidi, ale jelikoz se to pouze Home netyka, vas argument je nepravdivy.
"Windows, které mají správce, používají pro distribuci aktualizací WSUS." ...
Ne, nepouzivaj, protoze to nefunguje. Windowsy ktery maj spravce pouzivaj vsemozny samorobo scripty ktery se je snazej dokopat k tomu aby se aktualizovaly. Wsus je naprosto khovnu, protoze neumi ani takovou primitivni vec jako zjistit, jesli danej stroj nejakou aktualizaci potrebuje ... a odpoved kretenu v M$ je, ze je to tak prece vporadku.
Zrovna ted vsechny widlostroje na desitkach (vcetne tech serverovych) pry "needujou" podle wsusu 110 aktualizaci. Ale kazdej jeden nareportuje, ze zadny dalsi nejsou.
"Azerbaijani (Latin, Azerbaijan)" LanguageInterfacePack - Windows 10 Version 1703 for x64-based Systems - (KB4016509) [az-Latn-AZ_LIP]
"Hausa (Latin, Nigeria)" LanguageInterfacePack - Windows 10 Version 1703 for x64-based Systems - (KB4016509) [ha-Latn-NG_LIP]
"Serbian (Cyrillic, Bosnia and Herzegovina)" LanguageInterfacePack - Windows 10 Version 1703 for x64-based Systems - (KB4016509) [sr-Cyrl-BA_LIP]
"Uzbek (Latin, Uzbekistan)" LanguageInterfacePack - Windows 10 Version 1703 for x64-based Systems - (KB4016509) [uz-Latn-UZ_LIP]
Mala ukazka toho co prej ty widle nutne potrebujou ...
Pane J:
To co popisujete je důsledkem toho, že jste ve WSUS konzoli zaškrtl že chcete dostávat přes WSUS Windows 10 language packy.
Když jste je potřeboval, nevím proč si zde stěžujete.
A za druhé - tajemné kouzlo WSUSu je v tom, že si můžete aktualizace o které nemáte zájem odmítnout. Klienti pak nebudou hlásit že je potřebují.
Přeji pěkný den.
2bez přezdívky : Ano radis se k tem kokotum z M$, maj na to svym foru thread s +- 10 000 posty ... pokud je nekde napsano NEED = vyzaduje/potrebuje ... tak to rozhodne NENI aktualizace, kterou MOZNA NEKDY NECO ...
A jiste, bude kazdej admin co tejden prochazet 10k aktualizaci a vyhazovat z nich tyhle kokotiny ... jenom proto aby mu to nereportovalo picoviny.
Zajimavy ze se tam nevypisuje hromada dalsich aktualizaci, ktery si do tech widli taky muzu rucne nainstalovat ...
Všiml jste si, že čím slušněji Vás oslovuji, tím hruběji píšete?
To vaše "MOZNA NEKDY NECO " řeší on-demand aktualizace které nejsou needed. Např pro novější desítky .net framework 3.5. Ale máte pravdu, že se to zatím používá méně než by mohlo.
Needed u jazykového balíčku dává docela smysl, když chcete mít na WSUS jazykové balíčky (já tedy ne). A chcete tam mít téměř všechny větové jazyky, tak WSUS jasně hlásí, že má v databází něco co klient nemá nainstalované. Můžete je tedy bud odmítnout, nainstalovat, nebo ignorovat.
Nenapadá mě které aktualizace pro Windows 10 nejsou na WSUS, ale pro ostatní systémy občas vycházejí hotfixy které jsou dostupné na update catalogu. Z catalogu je můžete imporotvat do wsusu. Například SMB patch pro XP/2003 naposledy.
Stačí definovat pravidla a je to kompatibilní napříč verzema:
1. Pravidla se prochází postupně. Platí poslední bezchybná verze klíče.
2. Pokud se změní formát, definuje se nový klíč.
3. Neznámý pravidlo se ignoruje
4. Chybějící klíčový parametr znamená chybu a služba se nespustí
Stará verze:
USER = LOJZA
funguje OK.
USER označeno za zastaralý, náhrada USERNAME:
USER=LOJZA
USERNAME=LOJZA
ze začátku funguje tak, že se použije USER, pak obojí, nakonec USERNAME. Přechodný období funguje, na konci se objeví warning na zastaralý USER.
Po odstranění USER z kódu je starý nastavení ignorováno, přechodová verze funguje dál, USER možno smazat. V nové verzi stačí
USERNAME = LOJZA
Je to tak velký problém, aby kvůli tomu museli dělat takový problémy? Přechodná verze bude fungovat v obojím. A kdo neaktualizuje balíky, neaktualizuje ani systemd...
A proč ne? Pokud mám jasně daný pravidla, jak se postupuje s úpravou souboru a jasně dokumentovaný volby v něm, tak jsou tyhle možnosti:
a) Uživatel neupdatuje, tak se mu to nemá jak rozbít.
b) Správce aplikace neupdatuje, tak se to rozbije (ale dá se to fixnout použitím staré volby, kterou by nový systemd ignorovalo a on v aplikaci ignoruje novou volbu)
c) Aplikace bude udržovaná a holt se použije to, co je aktuální
d) Použije se nějaká komponenta na parsování s dokumentovaným API, sdílená mezi aplikacema, co s tím souborem pracují.
Kdežto když nechám klíče "jak jsou, aby to bylo kompatibilní", jsou tyhle možnosti:
a) Uživatel neupdatuje, tak se mu to nemá jak rozbít.
b) Správce aplikace neupdatuje, tak se to rozbije na neznámým formátu parametru (tebou vychvalovaný prefix). Fixnout se to obecně nedá, protože stejný klíč s různou hodnotou.
c) Aplikace bude udržovaná a holt se použije to, co je aktuální
d) Použije se nějaká komponenta na parsování s dokumentovaným API, sdílená mezi aplikacema, co s tím souborem pracují.
Takže když změním název klíče, mám možnost pro nekompatibilní program dál používat starý. Když změním jenom formát dat v tom klíči, se starým systémem to obecně fungovat nemusí. To je celý rozdíl.
====
Systemd nevidí do hlavy správci, aby mohl rozpoznat každou nesprávnou konfiguraci.
====
?? Očividně o té chybě ví, když ji zaloguje jako warning.
====
Nejde jen o zpětnou kompatibilitu se staršími verzemi systemd, jde i o kompatibilitu s jinými aplikacemi, které používají unit soubory.
====
Máš nějaký konkrétní příklad? Tomu argumentu nerozumím. Proč by měl systemd akceptovat formát svého vlastní direktivy, kterému nerozumí (a jen to přejít logem), jenom proto, že jej může používat jiná aplikace? Ta si přece může použít jiný název direktivy.
=====
Tady se ukazuje rozdíl mezi správci, kteří po napsání jednotky otestují, zda funguje, a zkontrolují logy, a správci, které nějaké varování nezajímá a řeší až případ, kdy jim služba vůbec nenastartuje (a nejspíš je pak na to stejně musí upozornit někdo jiný).
=====
Pokud se mi služba i jen pro otestování spustí pod rootem, může to nadělat pěknou paseku třeba na filesystému - vyrobí mi klíčové soubory pod rootem a budu pak pěkně dlouho dohledávat a měnit práva souborů, aby mi zase běžela pod neprivilegovaným userem. Zkus si takto spustit třeba mysql, když bude při spuštění vyrábět ibdata + adresáře/soubory systémových db pod rootem a máš o práci postaráno. To mohu tak testovat leda v kontejneru.
Očividně o té chybě ví, když ji zaloguje jako warning.
Systemd očividně rozlišuje mezi chybou a varováním.
Máš nějaký konkrétní příklad? Tomu argumentu nerozumím. Proč by měl systemd akceptovat formát svého vlastní direktivy, kterému nerozumí (a jen to přejít logem), jenom proto, že jej může používat jiná aplikace? Ta si přece může použít jiný název direktivy.
To není direktiva systemd, je to direktiva jednotky (unit file). Jiná aplikace je třeba budoucí verze systemd. Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby. Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.
Pokud se mi služba i jen pro otestování spustí pod rootem, může to nadělat pěknou paseku třeba na filesystému - vyrobí mi klíčové soubory pod rootem a budu pak pěkně dlouho dohledávat a měnit práva souborů, aby mi zase běžela pod neprivilegovaným userem.
Taky si má nejdřív správce zkontrolovat, co spouští. Když takhle spustí přímo MySQL nebo nějaký skript, může napáchat úplně stejné škody.
V případě jednotky ale správce tu službu nemusí hned spouštět, může nejprve na jednotku spustit systemd-analyze verify, která mu ta varování vypíše bez nutnosti jednotku spouštět.
======
Jiná aplikace je třeba budoucí verze systemd.
....
Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby.
======
Samozřejmě. Protože když změním formát a ponechám název volby, stejně jsem rozbil onu zpětnou kompatibilitu nové unity na starý systemd. Starý systemd nový formát nepozná a volbu ignoruje - tudíž jsem nic nenastavil a nastartovaná služba (s warningem v logu) nefunguje správně. Zatímco když přidám novou volbu, mohu mít v unitě obě dvě a udržet zpětnou kompatibilitu pro starší verze, minimálně po nějakou dobu. A unita může být tak kompatibilní pro více verzí systemd. Dokonce bych v ní mohl uvádět rozsah verzí.
A nebo zpětnou kompatibilitu konfigurace nevyžaduji a mohu formát změnit s tím, že starší verze zahlásí chybu a skončí. Systemd má přece možnost přetížit konfiguraci konkrétní unity v /etc/systemd, používá se třeba pro zkrácení nesmyslného nekonečného timeoutu při změně síťovky v networking.service. Tak konkrétní volbu přetížím správnou hodnotou pro mé staré systemd a služba normálně najede.
Také se musím nějak popasovat s tím, že zvolili takovýto divný postup, nic jiného mi nezbývá. Ale mohu to kritizovat, a ne obhajovat, že je to tak správně a logické.
To, že se přidal formát, neznamená nutně, že nová jednotka se starým systemd nefunguje správně. Když se k volbě Description přidá možnost prefixem @lang= zadat jazyk popisku jednotky, start služby to nijak neovlivní.
Vy to pořád popisujete, jako kdyby to byl formát jen pro systemd – jenže tak evidentně nebyl zamýšlen.
Mně se ten formát nelíbí, radši bych formát, kde se příznaky nebudou zapínat tím, že se použije nový formát zápisu hodnoty, radši bych formát, kde bude možné udělat podmínku na zpracovávající aplikaci nebo její verzi. Ale autoři systemd zvolili tenhle formát, a v rámci toho formátu je to chování logické a konzistentní.
Já osobně považuju formát jednotkových souborů za to nejhorší na celém systemd, ale prostě zvolili takovýhle formát a to, že různé formáty hodnot voleb budou označovat různé chování, tak to respektuju.
Já osobně považuji tento formát za velmi vhodný.
Prostě ini-like, [sekce] klíč=hodnota
Stejný formát napříč vším, logind.conf vypadá stejně jako .network nebo .mount. Tohle mi vyhovuje.
Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.
Váš přístup by znamenal, že s každou změnou formátu by se musel změnit i název volby.
Což by bylo správné řešení. Pokud by si někdo vymyslel seznam uživatelů, klidně může vzniknout UserList=. Nevidím na tom nic špatného, právě naopak, protože seznam uživatelů je evidentně něco jiného, než jeden uživatel.
Co mi nevyhovuje je, že někdo obhajuje, že klíč=hodnota vlastně není klíč=hodnota, ale že to ještě navíc záleží na syntaxi té hodnoty a vlastně to může znamenat něco úplně jiného.
To je přesně to, co mi na tom formátu nejvíc vadí. Jenže pokud by to mělo být jinak, s tím postupem [sekce] klíč=hodnota by to nejspíš nešlo. Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…
Stačí se podívat jenom na ExecStart, který se může opakovat a může obsahovat prefix @, + a -. Rozepsat do klíč=hodnota by šlo, ale jak by to vypadalo…
Vypadalo by to úplně normálně a hlavně by to nerozbilo zpětnou kompatibilitu. Prostě ExecStart je plná cesta k binárce a její parametry. Pokud si někdo později vymyslel @+-, stačilo zavést třeba ExecMod, do kterého by šlo zadat mod spouštění (třeba jako bitmapu, nebo pomocí symbolů @+-). Vůbec to není potřeba cpát do hodnoty parametru ExecStart a porušit tím předchozí kompatibilitu (@/bin/bash evidentně není validní cesta k souboru).
Jenže ExecStart se může opakovat a ty prefix se týkají každého příkazu zvlášť. Navíc ty modifikátory nemusely být zavedeny najednou, takže pak by pro ně nestačil jeden ExecMod, ale podle pravidla „při každé změně novou volbu“ by těch voleb muselo být několik. Takže ze současného
ExecStart=@+-/opt/backup/run-backup.sh backup-home ExecStart=@+-/opt/backup/run-backup.sh backup-var ExecStart=/opt/backup/upload-backup.sh
by se stalo
ExecStartArgv0=backup-home ExecStartFullPrivileges=yes ExecStartIgnoreError=yes ExecStart=/opt/backup/run-backup.sh ExecStartArgv0=backup-var ExecStartFullPrivileges=yes ExecStartIgnoreError=yes ExecStart=/opt/backup/run-backup.sh ExecStart=/opt/backup/upload-backup.sh
Ten první zápis je hrozný, ten druhý je ještě horší.
Ten první zápis je hrozný, ten druhý je ještě horší.
Tak to je otázka vkusu. Asi jako všechny flamy v historii o tom, která syntaxe je lepší, která horší, která je úsporná a která je readonly.
Mě osobně druhý zápis nijak nevadí. Pokud by se to naformátovalo pěkně, tj mezi každou skupinu ExecStart dala třeba mezera, tak osobně nemám problém s čitelností.
Ale to je věc vkusu.
2Dustin: "...To mohu tak testovat leda v kontejneru." ... nemuzes, se sytemd je lepsi ani netestovat. Protoze i kdyz dojdes cirou nahodou k tomu, ze to asi funguje, tak to jeste vubec neznamena, ze to bude fungovat i za 10 minut. Jeden takovej pokusnej stroj sem nakou dobu mel ... a pokazdy kdyz sem po mesici chtel neco vyzkouset, bylo tuhy sshcko. Zjevne se systemd rozhod, ze ho zrovna neni treba ... a uz nikdy nenabehlo ...jo, byl to prakticky cistej centos ...
systemd ignoruje volby, které nezná. Nehodnotím teď, zda je to dobře či špatně. Naposledy jsem narazil na MTUBytes, kde to na starší verzi sice prošlo, ale MTU se nenastavilo. V logu byla chyba, že to MTUBytes nezná. Ok, dejme tomu, to je jiné téma.
Jenže položka User je pro systemd známá.
Problém vidím v tom, že zatímco za neznámého usera to zahlásí chybu (a poměrně hlasitě), tak za neparsrovatelného usera to volbu v klidu ignoruje a pustí to za roota.
Takže pokud admin zadá to tvé User=@"#! tak je asi zřejmé, že chtěl položku User nastavit (a tedy pustit unitu pod konkrétním uživatelem), jen tam uvedl nevalidní hodnotu. V takovém případě by měla unita selhat (prostě je to neexistující uživatel) a nikoliv tento řádek ignorovat.
Systemd neignoruje jen volby, které nezná, ale také volby, které mají neznámou syntaxi. Což umožňuje syntaxi volby rozšířit – třeba se později někdo rozhodne, že bude možné uvést seznam uživatelů oddělených čárkou, a použije se první, který v systému existuje. Jiná věc je, jestli je vhodný tenhle způsob konfigurace, kdy se různé nové volby zavádějí třeba tak, že se před hodnotu zadá nějaký prefix (plus, zavináč apod.).
Z hlediska syntaxe unit souboru zkrátka není rozdíl mezi tím, zda uvedu UserXXX=nobody nebo User=@"#!, v obou případech je to pro aktuální systemd neznámá volba (a v obou případech to něco může znamenat pro jinou aplikaci nebo pro budoucí verze systemd).
Proč pořád řešíte špatně zadanou volbu? Tady jde o případ, kdy správce zadal tu volbu zcela správně a s platnou hodnotou. Je tam prostě User=0day, což je normální platný uživatel.
Jak systemd reaguje na chyby je opravdu podružné. Tady je problém v tom, jak reaguje na platné username.
Proč pořád řešíte špatně zadanou volbu? Tady jde o případ, kdy správce zadal tu volbu zcela správně a s platnou hodnotou. Je tam prostě User=0day, což je normální platný uživatel.
Neznámá volba a neznámý formát hodnoty volby jsou pro systemd to samé. Obojí umožňuje kompatibilitu jednotek s jiným softwarem (např. budoucími verzemi systemd).
0day pro systemd není platný uživatel.
systemd neví nic, ten jenom plní instrukce. Ty musí být jednoznačný, jinak je nemůže admin jednoznačně sdělit.
1) Pokud je uvedena známá volba USER, má se jí řídit. Bez pardonu. Neprojde regexp a nenajde ho v db, chyba, nespouštět. Admin projevil přání specifikovat uživatele, asi pro to měl důvod. Pod roota nesmí, neví, pod koho. Není jiná možnost, než error.
2) Pokud chce někdo v budoucnu používat v USER seznam uživatelů, má USER označit za zastaralou a používat třeba USER_LIST. Když se vyspecifikuje, že pozděj uvedený platí a neznámý si ignoruje, tak je to na dva řádky - USER a USER_LIST, rozumí stará, nová a přechodná verze. Není důvod kvůli tomu prznit stávající verzi. Tam je warning s upozorněním na novou verzi plně na místě.
3) Parser nemá hádat význam volby, ten má být vždycky daný explicitně. Ideálně rozlišení USER a UID.
4) Teprv až nepadne v chybě a nezná hodnotu, může šaškovat s defaultem.
5) Nabízí se otázka, jestli nemít USER/UID jako mandatory volbu, bez které systemd jenom ukazuje prostředníček jak Lennart póvlu kolem něj.
Nabízí se otázka, jestli nemít USER/UID jako mandatory volbu, bez které systemd jenom ukazuje prostředníček jak Lennart póvlu kolem něj.
O tom žádná, defaultní root je nesmysl. Jen to ukazuje, že je ten projekt ušitý horkou jehlou a před rozšířením měl projít pár lety připomínkování. Stejně jako svého času to samé pro pulseaudio.
Jenže dnes už by to byl zásah do většiny stávajících unit filů, chápu, že nechtějí ničit dopřednou kompatibilitu.
Co je validní sytaxe pro username nemá co rozhodovat systemd. Mám systém s čistě číselným username. Problémy to dělá jen v případě aplikací, které se snaží být chytrejší, než správce. Od adduser jsem žádné varování nedostal, protože je beru z LDAP-u. A vše funguje.
Proč mi najednou musí začít kecat nějaké systemd do toho, že je něco špatně?
Mimochodem Jirsáku, takového b*ba jako jsi Ty jsem tu dlouho neviděl. Proč prostě nedokážeš pochopit, že to je chybné chování a připustit to? Proč musíš za každou cenu obhajovat každou blbost, kterou Lenart řekne? To nemáš soudnost, nebo vlastní úsudek? Třetina důvodu proč nesnáším systemd jsou lidi, jako jsi Ty. Kdyby byla v systemd chyba, že když pomocí vypínacího tlačítka morseovkou vyťukáš slovo „explode“, tak by počítač vybouchl a Lenart by řekl, že nikdo přece nemačká takhle tlačítka, že to není chyba, tak to taky budeš hájit, dokud Ti to někdo nepříjde namačkat na počítači? Chováš se jako malé děcko, měl bys konečně dospět.
Ne, to nezajistuje kompatibilitu, to je naprosta picovina ...
Jedna vec je, kdyz mam v konfiguraku neznamej parametr, pak je OK ho ignorovat stejne jako koment.
Uplne jina vec je, kdyz tam mam znamej parametr, pak ho ignorovat v zadnym pripade nic nesmi a pokud je v nem neco co neprojde, tak to proste nema nastartovat a ma to skoncit s chybou. VZDY
Kazda normalni vec si pak tohle kontroluje jeste pred tim nez se pokusi neco spoustet.
Pokud chci menit syntax user, tak si musim zmenit nazev parametru ... trebas na user006 ... uz jen proto, ze jakejkoli externi tool nemuze tusit, jestli toho usera ma vyplnovat v syntaxi verze 01, 50 ... nebo 132. Alternativne musi byt povinou soucasti konfiguraku trebas verze. A pak mi holt starsi verze aplikace zcela spravne pri startu vynada, ze mam konfigurak pro novejsi verzi a odmitne nastartovat.
Ale jo, du napsat tvurcum postfixu ... ze by trebas pri spatny syntaxi mohli proste tu vec odignorovat a nastartovat to jako openrelay ...
"...Pokud není uvedena nebo má chybný formát a jde o systémový unit file, použije se uživatel root..."
A to je presne ta ober-pitomost! Protoze spravna implementace by mela byt:
Pokud neni uvedena, pouzije se defaultni hodnota a pokud ma chybny format, sluzba se nespusti s chybovym hlasenim!
Tak ošetřovat se má pořádně. Jinak to vede k věcem (na webu) jako XSS atd. Dobře, každý se někdy utne atd. ale proč si prostě nedá říct?
Je ale více věcí, kde Linux kernel a nástroje nebo knihovny typické pro "Linux" jsou v porovnání s OpenBSD, FreeBSD, Solaris resp. Illumos prostě nedotažené, nedomyšlené nebo aktivně protiinženýrské (tzv. "broken by design"). Občas to prostě na některé komunity působí tak, že "hlavně že jsou free, ale aby psali slušný kód...". No nic, jen je mi prostě občas trapně.
Pokud je tam validní jméno, ale neexistujícího uživatele, tak se unita vůbec nespustí a přímo to vyplivne chybu na řádek (a unita je prostě failed):
# systemctl start t
Job for t.service failed because the control process exited with error code.
See "systemctl status t.service" and "journalctl -xe" for details.
# systemctl status t
t.service
Loaded: loaded (/etc/systemd/system/t.service; static; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2017-07-03 10:02:47 CEST; 4s ago
Process: 19175 ExecStart=/usr/bin/id (code=exited, status=217/USER)
Main PID: 19175 (code=exited, status=217/USER)
Kdežto s nulou na počátku prostě proběhne:
# systemctl status t
t.service
Loaded: loaded (/etc/systemd/system/t.service; static; vendor preset: enabled)
Active: inactive (dead)
A spustí se (ExecStart) to jako root:
Jul 03 10:03:43 raid systemd[1]: /etc/systemd/system/t.service:3: Invalid user/group name or numeric ID, ignoring: 0tomasxxx
Jul 03 10:03:43 raid systemd[1]: Starting t.service...
Jul 03 10:03:43 raid id[19569]: uid=0(root) gid=0(root) groups=0(root)
Jul 03 10:03:43 raid systemd[1]: Started t.service.
Když je v unit souboru neexistující uživatelské jméno (ale syntakticky správné), systemd to vyhodnotí jako chybu. Ale jedním znakem eskalovat privilegia v unit souboru je snadné – stačí před User= přidat # jako komentář, nebo místo User= napsat Usr= a vyrobit tak dnes neexistující volbu. V prvním případě (s komentářem) to ani nic nevypíše, v druhém případě systemd vypíše varování před neznámou volbou.
Doprkynka, ale tady se celou dobu resi to, ze systemd _nespusti_ sluzbu pod zadanym existujicim, a validnim, uzivatelem, misto toho ji spusti pod rootem.
Jsou dana pravidla na validni username + jsou nejaka doporuceni (napr. nezacinat pomlckou, povoleni znaku '$' na konci username). Ale systemd nema co brat nejake striktni doporuceni a udelat z nej tvrde pravidlo. To je bod jedna.
Bod dva je ta jeste sveraznejsi intepretace one sverazne striktni definice.
Jedno lepsi jak druhe.
To je ovšem něco úplně jiného, než tu řeší všichni ostatní – ale je to jediná skutečná chyba. Ano, může být problém to, že systemd neakceptuje uživatelské jméno, které na daném systému může reprezentovat skutečného uživatele. To bych systemd ještě odpustil, když někdo takového uživatele má, může použít jeho uid. Ale mělo by to být napsané v dokumentaci.
To je zajímavé, kolik lidí kope do LP. A proč?
Protože služba se spustí pod rootem místo pod špatně definovaným uživatelem.
Není také pravda, že aby bylo možné službu (unit file) vytvořit, tak dotyčný už má rootovská práva?
Pokud ano, tak to znamená, že dotyčný už roota má a v čem je tedy problém?
Tak co, už je LP dost ukamenovaný?
Pokud ano, tak to znamená, že dotyčný už roota má a v čem je tedy problém?
Takže když má správce roota (jako že má, od toho je to správce), tak to znamená, že mají běžet všechny služby pod rootem a je to vlastně jedno? :-D
Problém je v tom, že správce nastavil, že daná věc má běžet jako User=něco a místo, aby to běželo jako user něco, nebo to selhalo, pokud user něco neodpovídá pravidlům, tak se to spustí jako root. Může se jednat třeba o překlep, místo User=petr může někdo napsat User=0etr. A už to běží jako root. Petra to jistě potěší, ale co ty ostatní?
To si rovno môžeš písať Lennartom. Keď nepochopí ani takéto základné bezpečnostné prvky, je to zbytočne zabitý čas a viem si ho predstaviť využiť lepšie.
Zhodou okolností som na tento bug natrafil skoro hneď po vidaní a chcel som to vidať ako správičku, ale potom som si hovoril, prečo vlastne.
Tusis ze ti neco prileze s aktualizaci? A co kdyz nekdo naisntaluje rekneme apache ... a z nejakyho duvodu failne vytvoreni userera ... to se pak ten apache, aniz by si toho nekdo vsimnul, pekne pusti pod rootem ... ostatne, stejne jako ve widlich, tam taky vsechno bezi pod systemem nebo adminem zejo ...
Nehlede na to, ze ses negramotnej, protoze ono se to pusti pod rootem i v pripade, ze ten user normalne existuje, da se na nej prihlasit, ale curak poettering se proste rozhod, ze kazdej user zacinajici cislem je root.
O tom ze bys tusil ze se celkem bezne startujou servisy pod user accountama po prihlaseni toho kteryho usera ani nemluve .. mno a kdyz se proste prihlasi 0124vomacka ... tak se mu to spusti pekne pod rootem.
Ve Windows běží pod "systémem" tedy účtem SYSTEM jen ty nejdůležitější služby. Účet SYSTEM je lokálním administrátorem.
Ostatní služby pak běží pod Local Service či Network Service - to jsou neadministrátorské účty které se liší jen tím, jak se autentifikují po síti.
Nic vám samozřejmě nebrání spouštět služby pod libovolnými účty.
Problém je, že když USER=sqldb dám USER=3qldb, tak při SQL injection může kdokoliv cokoliv nejenom v DB, ale na celé mašině. A proč?
- Admin se překlepl
- systemd si myslel, že "3qldb" je číslo uživatele
- systemd zjistil, že "3qldb" není číslo, takže zahodil volbu USER
- systemd to bral tak, že když není platný UID, má použít default hodnotu
- systemd má jako default hodnotu to nejhorší, co může mít - roota
- a útočník má pak volný ruce na cokoliv.
Jak by to mělo fungovat:
1) USER byl čistě jméno uživatele
2) Pro UID byla volba UID
3) Parse error -> odmítne to spustit
4) USER nebo UID není v systému -> odmítne to spustit
3) Není zadáno UID nebo USER -> odmítne to spustit
Chybu může udělat každý, ale pokud se z ní někdo nepoučí a trvá na nesmyslu, tak je důraznější upozornění v podobě drsnější kritiky na místě.
Bohužel spousta zařízení přístupných s default heslem je realita dnešního internetu a rozsáhlých botnetů.
Nicméně tento problém není způsobený touto konkrétní "chybou" systemd a myslím si, že ani nemůže. Je to stejné jako tvrdit, že výrobce nožů může za to, že tudle Franta běžel s nožem v ruce, viděl ho Pepa, tak taky běžel s nožem v ruce, ale narazil do manželky a dořezal ji.
Takže výrobce nože na rukojeť nenapsal: Neběhejte s nožem a výrobce může za to, že Pepova manželka je dořezaná. Tak je to kretén, když řekne, že nic opravovat nebude.
Bohužel souhlasím s výrobcem nožů, že není třeba nic opravovat a o těch co tvrdí, že je to kretén, si myslím své. A bohužel mám zvláštní potřebu to říkat všem okolo.
To jsme se nepochopili. Já netvrdím že tato chyba může za nějaké botnety nebo co . .. Já tvrdím, že fallback na roota default a to s tou 0 je totální vagínovina a nemělo se to tam objevit. Ovšem psal jsem ten příspěvek (jako reakci) proto, abych tě upozornil, že ne všechny služby si uživatel instaluje sám a má tedy kontrolu nad unitfile. Nic o botnetech, nožích, Pepovi, Frantovi . . . . apod.
Díky.
Souhlasím, že se služba rozběhne pod rootem, když uživatel začíná číslem není zamýšlená vlastnost. Nicméně za bezpečnostní díru to nepovažuju, protože:
1. Unit file zavádí root uživatel, který by měl být dostatečně uvědomělý, aby si to zkontroloval
2. Výstup při spuštění této služby píše, že služba běží pod rootem
3. Automatická instalace služby z balíčkovacího systému je psaná lidmi, kteří jsou také uvědomělí a ověří, zda se služba pouští pod rootem.
Myslím si, že LP má pravdu, když tiket uzavřel s tím, že se nejedná o bug.
Nesouhlasím s názorem, že LP je kretén, naopak si myslím, že je to velmi inteligentní člověk.
Celkově je to podle mě díra, protože instaluješ pod rootem a v podstatě ti takto může přes unit-file (jak psala Kate i pokud tam dá User=root) získat práva administrátora. Třeba já o tom nevěděl, resp. nenapadlo mě to, neřešil jsem to, snažím se to používat co nejméně. Oba si to můžeme zkontrolovat. Ale co tzv. linuxový desktop pro ostatní uživatele? Vždyť takto lze jednoduše přijít k právům roota - stačí si nainstalovat nějaký takto zmanipulovaný balíček (automatická instalace z .deb/.rpm) - ani bů, ani bé, tu máš roota a hrej si . . . .
Podle vás je díra, že root může získat práva roota? Podle mne to žádná díra není, to že root má práva roota je přece úplně normální… A běžný uživatel nemá právo User změnit, vždy se to spouští pod jeho účtem.
User=root se tam ani dávat nemusí – služba se normálně spouští pod rootem, volba User je volitelná a umožňuje to změnit.
Jo, jenže jedna věc je instalace a druhá spuštění - když si uživatel vezme např. *.deb a instaluje ho s právy roota, tak se mu "rozbalí" do filesystému. Pokud mu ale intalátor službu zrovna nastartuje a bude tam User=root nebo nic, tak třeba deb balíček xyz.deb získá práva roota - na Widlích se tě to aspoň zeptá.
Resp. pokud by ti např při apt update nějaký balíček změnil své unit file na User=root a restl se, tak se dá říct, že nějaká 3. strana rozhoduje o tom, jestli si sama na tvému systému přidělí roota - a znova opakuji - pak (z logu) už může být pozdě . . Dokonce i logy by po sobě mohla uklidit . .. . To nevypadá moc bezpečně
User=root se tam ani dávat nemusí – služba se normálně spouští pod rootem, volba User je volitelná a umožňuje to změnit.
Jo, a přesně takhle se dělá bezpečný software. Admin chce omezit práva pro spouštěnou binárku, ono to nejde, tak se to spustí jako root...
S takovou se klidně můžu dočkat toho, že se nepovede zinicializovat nspawn, tak to systemd spustí přímo na daném systému.
Rozkaz zněl jasně, musíme to spustit. Nebylo čas lámat si hlavu jak...
Tomáš Crhonek, 9:21: Když admin něco chce, musí to systému nějak říct. Asi mám větší fantazii, než je běžné, ale dovedu si představit milion způsobů, jak chyba v jednotkovém souboru, kterou není možné nijak detekovat, může způsobit nějakou škodu. Stačí třeba do příkazů, které se spouští, zadat chybný příkaz. Systemd nemá jak zjistit, že jste chtěl do pre příkazu napsat rm -r /tmp/app, ale místo toho jste tam napsal rm -r / tmp/app. Můžete mít jednotku, která se spouští pod rootem, ale vzdává se nějakých capability – opět, když to zadáte špatně, nikdo nezjistí, že jste to myslel jinak. Některé služby dělají postaru su na uživatele samy – opět, když na příslušný parametr zapomenete, služba poběží pod rootem.
Od toho systemd vypisuje ta varování, když se mu něco nezdá. Ale jak byste to chtěl udělat, aby jednotkové soubory byly vždy bezpečné? Volba User bude povinná, ExecStartPre a ExecStartPost budou povinné, ve volbách Exec bude zakázáno rm a dalších asi milion podmínek, které budou bránit tomu, aby správce mohl napsat něco nebezpečného? Nebo kde má být ta hranice?
Asi mám větší fantazii, než je běžné, ale dovedu si představit milion způsobů, jak chyba v jednotkovém souboru, kterou není možné nijak detekovat, může způsobit nějakou škodu. Stačí třeba do příkazů, které se spouští, zadat chybný příkaz.
Stále vidím zásadní rozdíl mezi tím, kdy software ignoruje známou lvalue jen na základě hodnoty a mezi tím, kdy admin, možná omylem, napíše ExecStart=/bin/rm -r --no-preserve-root /.
Nebo kde má být ta hranice?
Tohle je fakt absurdní.
Ta hranice má být tam, co může systemd kontrolovat a co může systemd ovlivnit, co je v jeho gesci. Tzn je naprosto absurdní argumentovat tím, že do ExecStart si můžu dát příkaz pro odpálení atomové bomby a argumentovat tím, zda by to měl systemd kontrolovat.
Takže znova po sté: systemd by měl kontrolovat lvalue. Pokud lvalue zná (je to pro něj známá konfigurační volba), měl by se pokusit zpracovat její hodnotu. Pokud zpracovat hodnotu nelze, neměl by tuto lvalue ignorovat, ale měl by ohlásit chybu a celou unitu prohlásit za neplatnou. (+ jako bonus možnost nastavit striktní režim, že to nebude ignorovat ani neznamé lvalue, to bych si s chutí nastavil, ostatním to necpu)
Tímto způsobem běžný software hlídá chyby admina. Ano, pochopitelně existuje další milion možností, jak admin může systému uškodit. Ale to přece neznamená, že úplně rezignujeme na jakoukoliv kontrolu. (Kdysi BASIC na Didaktiku taky psal jen syntax error - a člověče najdi si to, dnešní kompilery poměrně přesně programátora navedou na výskyt chyby v kódu - podle tebe je to naprosto zbytečné, protože tu chybu lze ignorovat.)
Pane Jirsáku, stále si nerozumíme a stále se to motá dokola...
Když uděláte chybu (a to jednou uděláte), tak byste měl být přece rád, že systém zabrání (a tohle je v jeho silách), abyste vylil jakési neznámé binárce vnitřnosti systému k dispozici, přestože se pod uživatelem pepazdepa neměla k ničemu dostat. Když spouštíte nějakou službu, budete radši, aby za každou cenu jela, nebo aby vám nevyventilovala informace z jiných účtů či systému (nebo jej dokonce neupravila)? Nebavíme se tu o tom, že máte OS tip ťop, ale co se stane, když nebude.
SB, 11:20: Já vám rozumím. Systém té chybě může zabránit – ale jedině tehdy, pokud o ní předem ví.
Jednotkové soubory fungují tak, že mají nějaké volby, a těm volbám se zadávají hodnoty, které mají nějakou syntaxi. Pokud je ta syntaxe neznámá, systemd vypíše hlášku do logu a ignoruje jí. Možná řešení toho problému jsou dvě. Buď je možné určit, že volba User může mít libovolnou hodnotu – pak to skončí na chybu, že uživatel neexistuje, a budete spokojen. Jenže se tím zazdí možnost do budoucnosti přidat další volby pro položku User (třeba prefixem @ nebo + určit, že se má s názvem zacházet jinak – jako to má spousta jiných voleb v jednotkových souborech). Čímž se nesystémově zabrání jedné z milionu možností, jak může správce udělat chybu při konfiguraci jednotek. Druhá možnost je speciálně v případě User změnit varování na chybu. Proč ale zrovna v případě volby User, proč ne taky u jiných voleb?
Nejde o to, že ta služba má za každou cenu běžet. Jde o to, že s jednotkovými soubory se pracuje tak, že se neznámé volby ignorují. Pokud bude nějaké aplikace pracovat s jednotkovými soubory a nebude znát volbu Description, opravdu to má být důvod, proč s tím souborem odmítne pracovat? Když já si do jednotkových souborů přidám informace o tom, na kterých nodech clusteru se má služba spouštět, opravdu to má zabránit spuštění takových služeb, dokud neprotlačím do systemd a všech ostatních aplikací patch, že má tyhle volby ignorovat?
Já beru, že tu spousta lidí chce, aby se systemd choval jinak. Ale nikdo tu neměl tu odvahu, aby napsal, jak přesně se to zacházení s jednotkovými soubory má změnit. Třeba že se všechna varování mají změnit na chyby. Nebo že se se s volbu User má zacházet jinak. Ono je jednoduché, když vidím nějakou „chybu“, rychle vymyslet nějakou záplatu, která tu jednu domnělou díru zalepí – bez ohledu na cokoli jiného. Ale promýšlet to v celku, jak to ovlivňuje celkovou koncepci, zda tím náhodou nerozbiju něco jiného, jestli je to opravdu dostatečný důvod, proč porušit koncepci a zavést nesystémovou výjimku – to už je něco jiného.
Opravdu existují různý kategorie parametrů.
Třeba blbý rm, když mu nedám cestu, padne na hubu, protože mu chybí informace, kterou nemá jak získat. když vynechám -v, příkaz proběhne (jenom se chová trochu jinak).
Když se má něco automaticky spustit, tak je potřeba vědět, pod jakým uživatelem. Když mu to nikdo jednoznačně nezadá, nesmí hádat. Když už "hádá", musí "uhodnout" alternativu, která je nejbezpečnější.
Ehm. Zmanipulovaný balíček který vytvoří unit file s User=0neco je jeden z nejkrkolomnějších způsobů jak získat roota přes zmanipulovaný balíček. Proboha, pokud počítáš se scénářem zmanipulovaného balíčku, tak má jeho tvůrce bambilión a jeden způsob získání roota. A pokud trváš na krkolomných řešeních, úplně stejně jako přes ten unit file to jde získat přes sysv init skript.
V tomhle případě můžeš tedy za díru považovat samotnou instalaci balíčků pod rootem. Protože podvržený balík si může dělat v systému prakticky co chce a může zneužít init systém tisíci a jedním způsobem. Pokud chci přes podvržený balíček spouštět něco pod rootem pomocí systemd, proč bych se měla obtěžovat blbým User=123foobar, když můžu napsat rovnou User=root nebo User=0?
A hlavně, proč blbnout s jakýmkoliv initem, když můžu svým podvrženým balíčkem prostě do /bin vrazit shell s nastaveným SUID bitem?
NULL, 10:07: Právě jste překonal hranici mezi „opravdu o tom toho tak málo ví“ a „aha, ona je to jen čistá groteska“. Vám tedy prostě vadí, že root má na Linuxu neomezená práva, a viníte z toho systemd.
Mohl byste nastínit vaši představu, jak by se asi do Linuxu instaloval systémový software (nebo třeba jádro) tak, aby se nemohl spustit žádný kód pod rootem? Mohl byste nastínit, jak byste provozoval služby tak, aby žádná z nich nevyžadovala práva roota? Nebo co se vám nelíbí na systémových jednotkách, které může nainstalovat jenom root a které mohou běžet pod rootem? Chtěl byste, aby při každém startu takové jednotky musel root zadat heslo? Nebo jak byste si to představoval?
O ničem takovém jsem nepsal. Kde jsem napsal že nechci aby se cokoliv pouštělo pod rootem?
Aha, nikde.
Jenom jsem nastínil možnost, že takto může unita které třeba tebou v directivě User byly nastavena nižší práva získat vyšší. To mi jako problém připadá. Týká se to celého instalační processu? Ok, to ale neznamená že je to v pořádku.
Jak bych si to představoval? Asi nějak tak, že přestaneš tvrdit blbiny ad absurdum co kde kdo řekl a že to Velký Vizionář vyřeší, když už píše nový linuxový desktop ;-)
A nějak prakticky? Třeba že services rozdělí na systémové a ostatní a pro přidání do rootvských to budeš muset schválit ručně při instalaci, při změně . . . Může to být podle uživatelů kteří to mohou modifikovat a pouštět default, možností je víc, buď přes nějaký "kontroler" nebo právama na složky . . . Tím, že se budeš ostatním vysmívat a tvrdit že se nic neděje se to určitě nevyřeší. A stejně na to jednou dojde, když už má být systemd ta budoucnost lin. desktopu . . .
Balíčkovací systémy zpravidla nepřepisují uživatelsky změněné konfigurační soubory. Takže unita která má nastavená nižší práva šmahem nezíská vyšší.
Abys ovšem tohle mohl využít přes balíčkovač jako bezpečnostní chybu, musel bys přepsat celou service, změnit unit file… Prostě, přes podvržený balíček lze získat práva roota podstatně snazsším způsobem než takhle (navíc je to podstatně nápadnější)
Navíc se to NIJAK netýká této chyby a přes sysv init / upstart / bsd init jde udělat to samé.
"zpravidla" - to je něco mezi možná a asi, nebo kam to tak zařadit?
Proč bys musel měnit celou service? Stačí ti jeden řádek v *.service. No možná se to netýká, já taky nepsal že ano, této chyby, ale manažer služeb by asi měl řešit práva, pod kterýma to má běžet. Možná by tam sehrál roli ten fallback na roota . ..
V SELinuxu se toho dá nastavit dost a dá se tam taky nastavit, které položky který program může modifikovat a které ne a kam daný program nesmí. Já to používal akorát na Centosu pro Mailing a pro Apache, resp. httpd. Proto jsem taky psal "ale to už jenom tipuji a záleželo by i na nastevení."
Ne, aktualizace, ve které je ten unit file, může pocházet zvenčí a pod rootem na tvým stroji proběhne apt / dnf, pod rootem jede systemd. Ale to neznamená, že pod rootem musí jet to, co systemd spustí. A neznamená to, že roota na tvým stroji musí mít i ten, kdo ten řádek do souboru napsal...
A pokud budu mít balíček ze dvou dister, používajícich stejný balíčkovací systém, kde jedno akceptuje čísla na začátku user name a druhý ne, tak si nevědomky na tom striktnějším můžeš eskalovat práva. Jestli tohle není o bezpečnosti, tak co sakra o té bezpečnosti je?
Když se ta jedna distribuce rozhodne opatchovat systemd a místo volby User bude používat Usr, je to ten samý problém. Tohle je prostě obecně neřešitelný problém, systemd se to ve skutečnosti vůbec nijak netýká, a kde kdo se do toho strefuje jenom proto, že to někdo spojil se systemd a strefovat se do systemd je módní.
Patr M., NULL: Ve skutečnosti se tím akorát vyvalila obrovská neznalost, která panuje mezi „správci“. Několik lidí tady bez uzardění píše o tom, že je pro ně ohromné překvapení, že když spustí instalaci nějakého balíku pod rootem, provede se pod rootem cokoli, co je součástí instalace toho balíčku. To jste doteď nevěděli, že každý instalační balíček má možnost připojit skripty, které se provedou před instalací balíčku a po jeho instalaci (a jiné před a po odinstalaci)? Debianí balíčky mají preinst a postinst skripty, RPM mají skriptlety, ebuildy mají sekce pkg_preinst a pkg_postinst (a celý ebuild je shellový skript), ostatní balíčkovací systémy mají nepochybně něco podobného. Systemd s tím vůbec nijak nesouvisí, když budete mít špatně udělaný balíček, spustí vám pod rootem při instalaci balíčku nečekaný kód klidně na Devuanu. Mimochodem, ty pre- a post-instalační skripty se používají mimo jiné právě proto, aby zkontrolovaly podmínky nutné pro používání toho balíčku, takže například právě založí toho uživatele, kterého daná služba používá.
Nechtěli byste si místo kritizování něčeho, čemu nerozumíte, radši nastudovat základy správy balíčků?
Ten problém řešitelný je. Prostě directiva User bude poviná a hotové.
To víš že to vím, určitě i Petr M, ale tady snad ten Vizionář to měl konečně udělat správně ne? Hraje si na spásu v podobě system managera a jenom tam dává další díry, protože dřív jsi musel při restartu služby toto udělat s rootem a nemohl nikdo jiný. Dnes ti systemd toho roota klidně půjčí. Paráda.
A hned by spousta lidí na Rootu začala řvát, že je to hrozné, že jejich SysVinit skripty nic takového nemají a normálně se spouští pod rootem.
Nedělej ze sebe idiota. Ano, rc skripty jako takové možná běží pod rootem, ale když si tam admin dá:
# su -c 'id' 0kokotlennart
uid=1006(0kokotlennart) gid=1006(0kokotlennart) groups=1006(0kokotlennart)
tak to prostě jede.
(A ne, fakt už podruhé nemusíš psát absurdnost s tím, co se stane když tam admin zapomene dát to username. User=0kokotlennart v systemd danou věc spustí jako root, su 0kokotlennart pod existujícím uživatelem nebo vůbec, pokud user neexistuje.)
Jul 04 10:58:03 raid systemd[1]: /etc/systemd/system/t.service:3: Invalid user/group name or numeric ID, ignoring: 0kokotlennart
Jul 04 10:58:03 raid systemd[1]: Starting t.service...
Jul 04 10:58:03 raid id[8748]: uid=0(root) gid=0(root) groups=0(root)
Jul 04 10:58:03 raid systemd[1]: Started t.service.
Ale klidně si to tom napiš další referát, jak je to vlastně správně...
JE to KRETÉN. Root něco nainstaluje, to si vytvoří uživatele 0LPjedebil a pod tímto uživatelem se to spustí. Opravdu je potřeba kontrolovat každou kravinu, jak se chová ve skutečnosti, když je nastavená jinak? Co všechno si má admin zkontrolovat? Protože pokud nad každou takovou kravinou mávneme rukou, nakonec budeme muset kontrolovat úplně všechno, včetně zdrojáků, protože "root má být uvědomělý". No jestli ono nebude nakonec jednodušší, napsat si vlastní systém, ne?
Ono je potřeba si uvědomit rozdíly mezi chybama. Chyba může být za určitých okolností ignorována a děje se tak zcela běžně, ale nemůžu něco pustit jako root, když mi konfigurák tvrdí něco jinýho, třeba nesmyslnýho. Když se přihlásím do systému jako neexistující uživatel 0hacker s nečekaně chybným (neexistujícím) heslem, má mně systém přihlásit jako roota, nebo mě má poslat do Lenarta?
Opravdu je potřeba kontrolovat každou kravinu, jak se chová ve skutečnosti, když je nastavená jinak?
Zkontrolovat si konfig po každé změně je nanejvýš vhodné u každého software. Většina software na to má nějaký nástroj.
Druhá otázka je, jak by se měl software při chybě chovat. Podle některých lidí i zde v diskusi je možné řádek s divnou hodnotou ignorovat. K čemu to potom vede jsem demonstroval na příkladu MySQL. Tam ignorování ze strany software vedlo až k poškození dat.
Tzn. chyba by nikdy neměla vést k horšímu stavu. Pokud admin zadá (v tomto případě) User a toto není možné z libovolného důvodu provést, není možné mít jako fallback roota. Kdyby byl fallback nobody, tak se o tom ani nebavíme. Default má být bezpečný. Osobně preferuji variantu, že software s vadným konfigurákem vůbec nenaběhne. V případě systemd by se dalá unita mohla prostě ignorovat jako celek.
2MP: Ono je hlavne mnohem jednodussi nepouzivat distra se zhuverilosti systemd.
2Heron: A jak prosimte pri kontrole konfiguraku zjistis, ze ta naprosto jasna konfigurace, ktera naprosto jasne rika, ze si prejes pustit neco pod existujicim uzivatelem 0kokotlennart ... to ve skutecnosti spusti pod rootem? Takze budes pri kazdy aktualizaci procitat zdrojaky a zkoumat u kazdy jedny konfiguracni volby, jestli zrovna tvoji variantu ne pochopi jinak nez bys cekal?
Jinak v pripade systemovych veci je s deseti otaznikama i ignorovani nevalidniho nazvu parametru. Spousta daleko min podstatnych veci te vyfuckuje i s tim.
A jak prosimte pri kontrole konfiguraku zjistis, ze ta naprosto jasna konfigurace, ktera naprosto jasne rika, ze si prejes pustit neco pod existujicim uzivatelem 0kokotlennart ... to ve skutecnosti spusti pod rootem?
Kontrola konfiguráku:
# systemd-analyze verify t.service
/etc/systemd/system/./t.service:3: Invalid user/group name or numeric ID, ignoring: 0kokotlennart
To, že to ten řádek ignoruje a spustí pod rootem je samozřejmě špatně, ale o tom už tady diskutujeme druhý den, to nemusím opakovat.
Další je je samozřejmně to, že toho uživatele můžu v systému mít (useradd to nekontroluje, případně si to napíšu přímo do passwd nebo do ldapu) a přes to pod ním nelze spustit službu přes systemd.
Chápu, že podle tebe by v případě chybné syntaxe User neměl systemd vypisovat varování, ale rovnou chybu a spouštění jednotky přerušit. Má to být jedna jediná volba, která má mít takovéhle speciální zacházení? Nebo kterých dalších voleb se to má týkat? Nebo budeme čekat, až zase někdo vymyslí nějaký nesmysl a zadá to na GitHubu jako issue, a takhle budeme budovat ad-hoc seznam voleb, které mají speciální zacházení?
chybné syntaxe
Tohle je nádherná ukázka absurdity, do které se tato diskuse stočila.
Pro mě o žádnou syntaxe nejde.
User= pro mě znamená nastavení konfigurační hodnoty na string, který je za tím znakem =.
To, že pro někoho přišlo jako geniální nápad odhadovat, zda ta věc za tím '=' je číslo nebo řetězec a podle toho určit, zda se jedná o UID nebo o UserName, je podle mě zásadní chyba. Chyba návrhu. Tohle má být oddělené.
Jenže někdo si řekl, že hodnota nebude hodnota, ale že se bude aktivně parsrovat (viz šaškárna s ExecStart, když první argument už není plná cesta k binárce, ale někomu přišlo hrozně fajn tam narvat další znaky (které v absolutní cestě nemají co dělat), takže se bude odhadovat co je cesta, co není cesta a co je řídící znak, místo toho, aby určilo jiným parametrem (viz navrhovaný ExecMod), jak přesně se bude s daným příkazem zacházet.
Mimochodem, krásná ukázka toho, co se stane, když software odhaduje datový typ a použije nesprávný:
var_dump(md5('240610708'));
var_dump(md5('QNKCDZO'));
var_dump(md5('240610708') == md5('QNKCDZO'));
string(32) "0e462097431906509019562988736854"
string(32) "0e830400451993494058024219903391"
bool(true)
Funkce MD5 vrací 128b číslo, toto číslo je převedeno na nějaký string, dva stringy jsou porovnávané, porovnávátko odhadne, že jde o float, float je moc velký, nevejde se, tak to ořeže a výsledkem porovnání je true... (A fakt nepiště, co všechno je tam špatně a jak to udělat lépe, na to to téma už se popsalo stovky stránek jinde.)
S automatickým odhadem (většinou samozřejmě špatným) datového typu je vůbec super sranda. Tuhle jsem něco importovat do Calcu. Další nepoužitelný software.
Tomáš Crhonek, 11:23: Za prvé, to, že se pro uživatelské jméno a UID používá jedna položka, je naprosto běžné. Podobně jako se třeba používá jedna položka pro zadání hostname nebo IP adresy. Za druhé, ten problém spočívá v něčem úplně jiném. Problém je v tom, že systemd má omezenou množinu hodnot, které považuje za validní vstup pro User, a když tam někdo zadá hodnotu mimo tuto množinu, vyhodnotí systemd celou volbu User jako nevalidní a ignoruje jí.
Na tom, že tenhle formát konfiguračních souborů, kdy se před hodnoty přidávají různé znaky a tím se mění jejich význam, se shodneme. Ale ten formát je takhle zvolený, a za mnohem horší bych považoval dělat nějakou nesystémovou výjimku pro jednu volbu. Pokud už by se na tom mělo něco změnit, ať se změní typ volby User, ať je to libovolný text (třeba jako Description), a validita ať se posuzuje až za běhu podle toho, zda na daném systém daný uživatel skutečně existuje. Sice se tím rozbije statická analýza, protože User=@#!$ projde syntaktickou validací bez problémů, ale správci, kteří píšou do jednotkových souborů náhodné údaje a doufají, že to bude dělat to, co chtějí, budou spokojeni.
Naprosto běžný je, že někteří diskutující tady to mají trochu otočený.
Třeba jeden, co minulý týden zuřil, když registrátor u domény vezme z DNS bezpečnostní údaje, který se týden nezměnily a mají být dle definice propagovány, a začne je propagovat. Prý to vede k hypotetické chybě, ale popsat zneužitelnost neumí. A tady, kde je evidentní, že odladím něco na systému, který nepodporuje číslo jako první znak username, přenesu to na systém, který to podporuje (třeba s pomocí LDAP) a ono to samo eskaluje práva, tak se do roztrhání bije za to, že je to správně, protože to tak někdo definoval. Zvláštní to jedinec.
A že je něco běžný neznamená, že je to ta nejlepší alternativa. Třeba běžně používaný IPv4 pro připojení různých embedded věcí, co se pak nevidí skrz NATy a při vypnutí serveru dodavatele je z nich cihla.
A pokud mají být v konfiguráku atributy, je lepší použít třeba XML a tyhle modifikátory hodit jako atribut tagu. A sorry, rozpoznání XML od jinýho souboru je přece triviální věc, takže nevidím důvod, proč by třeba rok nemělo jít používat oba formáty.
Kdo chce, hledá způsoby, kdo ne, hledá důvody.
Petr M, 12:34: Zneužitelnost jsem popsal. Pokud něco odladíte na systému, který číslici na prvním místě username nepodporuje, máte v username v tom jednotkovém souboru username, které začíná písmenem. Když to přenesete na jiný systém, systemd to bude stále vyhodnocovat jako platnou syntaxi, a pak bude záležet jenom na tom, zda daný účet na systému existuje nebo neexistuje. Zkuste příště vymyslet nějaký příklad, kde dojde k nějakému problému. A mimochodem, pokud jednotkový soubor nevzniká v rámci instalace nějakého balíčku, který i vytvoří příslušného uživatele, ale ten jednotkový soubor jenom přenášíte mezi systémy, a ani si nezkontrolujete, zda zadaný arbitrární uživatel na cílovém systému existuje, je to vaše chyba. A představte si, že úplně stejně to funguje třeba s cestama ke spustitelným souborů. Vytvoříte jednotkový soubor na jednom systému, zadáte tam cestu k existujícímu programu, pak jednotkový soubor přenesete na jiný systém, kde ta cesta neexistuje – a představte si to, systemd má takovou drzost, že tu jednotku nespustí.
V tom, že XML formát by byl pro tyhle konfigurační soubory daleko lepší, se shodneme. Předpokládám, že spousta ostatních diskutujících bude mít za to, že XML je to poslední, co systemd ještě chybí, aby to byl ten úplně nejhorší software v celém univerzu.
Budování ad-hoc seznamu voleb, které mají speciální zacházení, je špatně. Na tom se shodneme. Momentálně ten seznam roste. Jak píše tato zprávička, přibyla tam položka "systemd neumí spustit jednotku pod uživatelem, jehož username začíná číslicí".
Jen nějak nechápu, proč vaše reakce formulujete tak, jako že vám ten seznam vadí, ale sám do něj nutíte další položku.
Systemd má prostě tři možnosti:
- prosadit do Linuxu podmínku, aby username nemohlo začínat číslicí
- upravit svůj program tak, aby akceptoval pravidlo Linuxu, že username může začínat číslicí
- připsat na seznam výjimek položku "Linux sice dovoluje, aby username začínalo číslicí, ale Systemd s tím neumí pracovat ve volbě User"
Karel 11:25: Ne, seznam položek jednotkových souborů, které mají speciální zacházení, je stále prázdný.
Systemd umí spustit jednotku pod uživatelem, jehož jméno začíná číslicí, akorát takového uživatele musíte zadat pomocí UID. Jediná skutečná chyba je to, že syntaxe volby User není zdokumentovaná. To, že některé hodnoty nejde do jednotkového souboru zadat jednoduše, je normální – třeba cestu k souboru, která obsahuje mezeru, tam taky nevložíte tak, že jednoduše cestu i s mezerou zkopírujete a vložíte.
upravit svůj program tak, aby akceptoval pravidlo Linuxu, že username může začínat číslicí
A pak přijde někdo, kdo si do /etc/passwd dá jako username kus programu v Perlu, a bude se to opakovat celé znova.
@Filip Jirsák:
Očekával bych, že to bude podporovat alespoň POSIX, jako všechny ostatní nástroje:
3.278 Portable Filename Character Set
The set of characters from which portable filenames are constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
3.431 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2008, the value is composed of characters from the portable filename character set. The <hyphen> character should not be used as the first character of a portable user name.
Skutečná chyba?
1) Nedokumentovaný chování volby user=
2) Volba user= není jednoznačná - existuje-li minimálně jeden systém, kde user name může být číslo a současně se to číslo neshoduje s uid, systém nemůže uhodnout, co ten string reprezentuje.
3) Parsuje se string, kde nejsou jenom číslice, jako integer
4) V situaci, kdy je evidentní, že něco nemá být spuštěno pod rootem (definováno user= a za rovnítkem není root - evidentně kvůli omezení práv a pro to je vždycky dobrý důvod) se služba spustí jako root bez omezení
5) Neexistuje bezpečný default pro user= nebo povinnost explicitně specifikovat uživatele.
6) systemd má na starost někdo, kdo když se dával rozum, šel si potřetí stoupnout do fronty pro aroganci (podruhý to bylo, když se rozdávala empatie).
Takze znova hovadko, copak asi tak udelas, kdyz ten (podle tebe blbej admin) napise servise, ze se ma spustit pod userem 123franta ... a ten user v systemu normalne existuje a da se na nej prihlasit. ... Jo aha, kreten jako ty to pusti pod rootem, protoze to je prece logicky zejo ...
Nj, to je tak, kdyz je nekdo dement jako ty ...
A ještě jednou:
Kdo to říká,
ten to je,
na toho to
pasuje
Když mi řeknou, že se to má spustit pod uživatelem 123franta, tak jim řeknu, že vlastnost systému je, že to nejde, jinak se to spustí pod rootem a doporučím jim použít jinou distribuci, pokud na tomto požadavku trvají. Předpokládám, že by na tom netrvali. :-)
Někdo hledá problémy a jiní hledají cestu.
Zásada defenzivního programování:
Pokud máš možnost, aby tě kompilátor nepustil dál při chybě, využij ji.
Obdobně, zásada defenzivní administrace by měla být:
Pokud máš možnost, aby se systém nespustil dál při chybě, využij ji
Jak vidím, systemd jde proti téhle logice. Chyba tam je, dokonce detekovaná, ale odbude se (někdy) warningem a jede se dál. Lennart je prostě superman, nedělá chyby a podle sebe soudí ostatní.
Ne, mělo by to fungovat:
1 - Hodnotu USER parsovat jako int
2 - Byl to int - použít to jako UID
3 - Nebyl to int - použít to jako jako username
4 - (rezerva, pokud username má nějakou zvláštní syntax, použije se zvláštním způsobem, to bude implementováno v budoucnosti, nyní jen goto 5)
5 - UID nebo username je platný - použít ho
6 - UID ani username nejsou platné - ERROR
Nj, ale to by se nikdy nepouzil ten uzasnej default s rootem .... ;D. A navic by to zcela jiste bylo pomaly ...
Takze spravnej soudruh to v ramci plneni na 130% .... udela nasledovne ...
1) nastartuj servisu pod rootem
2) zjisti, jestli nahodou neni v konfiguraci neco co umis
3) kdyz tam nahodou je, hod si kostkou (= libovolnym, ale hlavne rychlym zpusobem vyber jestli se ti libi nebo ne)
4) kdyz se ti libi prehod provoz na nej
Vidis, a sem i o 2 kroky rychlejsi nez ty ...;D
Netřeba vymýšlet kolo, když coreutils ( chown, setfacl, …) to už dávno řeší. Hodnota se použije jako username, a pokud takový uživatel neexistuje, tak se zkusí použít jako UID. UID lze vynutit tak, že se před číslo napíše plus (+), protože to stále lze parsovat jako číslo pomocí strtol a username jej nemůže obsahovat.
Ok, asi to neni po prakticke strance takova katastrofa jako tahle nova chyba pro 1704 a 1610:
https://www.itwire.com/open-source/78781-systemd-flaw-leaves-some-linux-distros-open-to-attack.html
Ale stejne nepochopim, PROC to tu nekteri lide haji blbost jako featuru. Prebytek casu? Laska k trollingu? Outsourced clickbot root.cz?
Tak to prece taky neni zadna chyba - Poettering jasne rekl, jaky format DNS odpovedi ceka a kdyz dostane neco jineho, tak to ignoruje, prepise pamet libovolnym obsahem a jede se dal - je chyba admina, ze pripusti aby pane Poetteringuv neskonale dokonaly system dostal data v jinem formatu.
Na druhou stranu se mi na reseni podobnych problemu osvedcil jeden jednoduchy trik, ktery celou tuto sadu problemu resi - nepouzivat systemd
Systemud má být úplně jedno jaká je syntaxe uživatele. Buď ho najde, nebo ne. Tím do toho vrazili jenom další klín, který bude potenciáně tvořit nekompatibility, někdo to bude muset hlídat, udržovat kompatibilní s distry a ostatně takto vznikl i tento problém o kterém se tu diskutuje . . . kdyby systemd pouze zkontroloval jestli user existuje, přopadně jestli jsou to všechno čísla (ne jenom první - jakkoliv) a jestli nexistuje jako UID, tak tato zprávička nebyla.
To je presne ten pristup, ktery odporuje zdravemu rozumu a pripomina neblahe zkusenosti s adminovanim Windows. Povolit/spustit vse co neni explicitne zakazane/zablokovane, antiteze POLA. Jednoznacne neidentifikovana hodnota volby (User) sluzbu spustim (jako root). Nebo ten jejich resolved fallback na DNS servery Google Inc. Jen aby to neco delalo, bez ohledu na vuli uzivatele.
Dekuji, nechci..
Nepouzivej, nemusis)
A neni to neidentifikovana hodnota,ale syntakticky nespravna. Neexistujici,syntakticky spravne zapsany, uzivatel se chova jinak.
Ja bych to takhle asi taky neimplementoval,ale logiku to ma a unoznuje to dobre rozsirovat ten format v budoucnu.
Takze pokud je to zdokumentovano, za me ok.
Jiste, celkem logicky se mi apache spusti pod rootem, protoze nenasel uzivatele ... maily se pustej taky pod rootem, protoze se nenasel uzivatel ... proc vlastne mit takovejch zbytecnejch zaznamu, kdyz se vsechno da spustit rovnou pod rootem. Stejne jako ve widlich, tam taky netreba jinych useru.
V tuxu existuje JEDINA aplikace, ktera muze resit format username ... a ta se jmenuje useradd. Vse ostatni ma maximalne zjistit, jestli danej user existuje a kdyz ne tak se to vubec nema spustit. Tecka.
Muzes je mit v ldapu a na hromade dalsich mist ... princip je ten, ze nikdo nema co zjistovat validitu formatu uzivatele, ma proste standardne overi jestli uzivatel existuje a kdyz ne tak skoncit.
Je to asi tak stejny, jako kdybys v textovym editoru pri ukladani overoval sektory na disku ...
S každým dalším průserem systemd, se jen utvrzuju v tom, že nám bohužel linux skrzeva systemd a podobné uchylnosti solidně windowsovatí... Nějak mi pořád ale není jasné, proč se snaží (blbě a s chybama) řešit i věci, které řešit netřeba, např resolving (systemd-resolved) nebo syncení času (systemd-timesyncd), nastavení sítě apod..... Co je na lokálním bindu nebo dnsmasq, případně ntpdate nebo chrony špatně, že musí vrtat i do takovýcho věcí.
Už se těším na systemd-firewalld, nebo systemd-filesystemd a podobné lahůdky.. Je mi z toho smutno - rozhodně to nejsou breky, že bych se musel něco učit nového.. to mi vůbec nevadí... jen je mi prostě smutno jak se nám to postupně plíživě rozbíjí... Možná by mohl jít do politiky, tam taky dělají "víc" než slibují :D #kňú
Chyba nie je v tom, ze si Poettering masti taketo veci do jeho vysnivaneho systemd. Nech si tam namasti aj predpoved pocasia, to je jeho vec.
Chyba je len to, ze cely tento kybel sraciek vacsina distribucii zacala pouzivat ako vychodzi init (s tym, ze na ine inity vobec neberu ohlad) a s kludom sa pozeraju, ako to postupne poziera dalsie veci (polkit zozrany, udev dalsi na rane), a rozbija funkcnost existujucich (a aj s init-om nesuvisiacich) veci.
Keby v riadeni distribucii mali ludia aspon trochu sedliackeho rozumu, tak uz by po vsetkych tych pruseroch hnali systemd von z distribucie svinskym krokom. Pretoze toto bude len eskalovat...
Pripadne by sa dalo vykazat systemd do patricnych medzi (udrzovat moznost alternativ a teda univerzalnost OS), aj ked to je z dlhodobeho hladiska dost unavne, pretoze systemd je stale nestabilny, stale sa tam menia veci, teda je logicke ze raz za cas sa objavia rozne problemy.
Lenze vsetky velke distribucie su dnes riadene menezersky (aj tie, co sa naoko tvaria ako komunitne). A tak ako zle menezerske rozhodnutia vo velkych americkych bankach (ohladom "toxickych hypotek") sposobili svetovu financnu krizu, tak aj siroke prijatie systemd (a jeho praktik rozbijat vselico naokolo) v linuxovych distribuciach speje ku krize (osobne si myslim, ze to najhorsie este len pride, tieto epizodky zatial, to su len take naznaky).
To víte, takový už je Linux – když máte třeba deset DNS resolverů, nikomu to nebrání rozhodnout se, že mu žádný nevyhovuje a napsat jedenáctý. A vy se zase můžete rozhodnout, který z těch jedenácti resolverů budete používat. Windowsovatění to určitě není, ve Windows to funguje přesně opačně – pokud se Microsoft rozhodne, že vám musí stačit DNS resolver vestavěný v systému, tak s tím nic neuděláte.
teď se LP rozhodl že uset začínající na 0 je root
Ne, nerozhodl. Ten problém spočívá v něčem úplně jiném. Pod rootem to poběží vždy, když hodnota User není zadaná nebo je syntakticky špatná. Takže to pod rootem poběží i tehdy, když zadáte Usr=nobody, User=1nobody nebo User=@#!$. A ve všech případech to vypíše varování do logu, že ignoroval neznámou konfiguracu.
systemd-resolved nikdo jako jediný resolver neprotlačuje. Máte možnost ho využít, když chcete. Nic víc, nic míň.
Ano, ale o tomto chování rozhodl LP. Můj osobní subjektivní názor je, že je to vagínovina. Pokud není User uveden, budiž spustit to pod userem který to startuje. Ale pokud je tento parametr zpatlaný nebo s chybnout hodnotou - error - stejně je to špatně a i když to na krásně pojede, tak to stejně jede zjenvně chybně, když to má chubu v konfiguraci - tedy není důvod aby to startovalo - ne tak s potenciální hrozbou běhu s právy roota ještě ke všemu proboha. O tom, že když při updatu do unit file pošllu Us=0haha tak si získám přístup k systému s rootem, se ani nebavím. Máme 50 tis bal. na debianu a kdoví co ještě, parádní díra . ..
jarda mira, 9:39: Nikoli, asi jste nečetl pozorně. Já tvrdím, že je v pořádku, že systemd chybné hodnoty ignoruje a napíše varování do logu – znamená to, že je kompatibilní s jinými aplikacemi, formát jednotkových souborů se může rozvíjet. Zároveň platí, že se systemd chová úplně stejně, jako všechny ostatní správce služeb – tedy když není řečen jinak, službu spustí pod rootem.
Je tady spousta lidí, kteří obhajují, že volba User je něčím speciální a měla by se zpracovávat speciálním způsobem. Proč zrovna User, proč ne taky Exec*, WorkingDirectory, *Paths a spousty dalších? V jednotkových souborech je tolik příležitostí, jak něco pokazit…
To že pokud je volitelná hodnota v nastavení (která má nějaký definovaný default fallback) nastavena na nesmysl / neznámou syntax, ignoruje se a použije se default je naprosto normální praxe ve spoustě konfiguráků. Tohle považuji za správné jednání a výhodnou věc pro zpětnou kompatibilitu.
Co mi přijde jako chyba je, že ač málo používaný, username s číslem na začátku prostě legální username je. V SystemD by se mělo opravit tohle jakožto špatně zvolený možný formát username, ne to chování jako takové.
Tj ... sshcko se defaultne pusti bez hesla, mtacko jako openrelay ... takhle nejak to myslis ze?
Jo aha, oni normalne jak vyvojari tak maintaineri balicku maji aspon pulku mozku, takze kdyz tam neni konfigurace trebas vubec zadna ... tak to pustej tak maximalne na localhostu. A nekdy ani to ne, hromada veci ma v konfiguraku prepinac, a dokud neni na "on" tak to proste vubec nenastartuje.
To chovani JE naprosto chory i jako "jen default", protoze pokud by tam vubec nejakej mel bejt (jako ze nemel) tak by to mel bejt nobody, coz je vetsinou prave ten user, kerej nema opravneni vubec nikde a tudiz kdyz se pod nim nahodou neco spusti tak to vetsinou (naprosto spravne) nebude fungovat. Coz je v tomhle pripade zcela zadouci chovani.
Ano, problém spočívá v tom, že to při chybě běží pod rootem. O tom, že takové chování není vhodné, snad nemá smysl diskutovat. Když už zvolili tak nešťastný default (root), se kterým nemohou z důvodu legacy konfigurací hnout, měli by se podle toho chovat a při problému to nepustit dál. To by nebyla žádná velká změna chování. Jaká jiná aplikace používá jiný formát položky využívané i systemd, jak o tom stále mluvíš jako o možnosti? O žádné takové nevím. A pokud by byla, holt se předělá, je stejně nesmysl, aby dvě aplikace používaly stejnou položku konfigurace a očekávaly každá jiný formát.
Vanilla shadow utils (useradd) pridat takoveho uzivatele nedovoli, nektere distribuce (debian ci rhel) maji balicek patchnuty a dovoli to. Z logiky veci by si tedy mely patchnout i systemd.
V realu, je to fuk. Takovych uzivatelu je nula nula nic, fakt je i to ze uzivatele zacinajici cislem jsou hodne problematicci (treba takovy username 2000 s uid 3000 je lahudka), posix se to u nekterych utilit snazi resit specifikovanim priority username, ale celkove si myslim, ze to zpusobi vic problemu nez uzitku. Za me idealni ponechat omezeni co ma vanilla useradd.
Je jedno, kolik takových uživatelů je. Stejně tak můžeš argumentovat pro zrušení trestu za vraždu, protože kolik vrahů mezi náma je?
Pokud distro dovolí nějakou volbu a jedna její součást se začne chovat nekorektně, je to problém. Pokud je reakce na volbu uživatele (který je ve zbytku systému korektní) eskalací privilegií, už to není problém, ale průšvih.
A právě kvůli "user 2000 s uid 3000" je potřeba v unit file striktně rozlišovat USERNAME a UID. Ne proto, že by to nemělo nastat, ale proto, že se to na některým distru může stát.
Celý systemd je ukázka toho, že navrhovat systémový software není žádná legrace, jak by se někomu mohlo zdát.
Ovšem na druhou stranu...
1. Pokud jde o Poetteringovo chování, tak osobně jsem toho názoru, že software se demokraticky vyvíjet nedá. On má nějaké své představy, jak by to mělo vypadat, včetně koexistence se zbytkem systému, a pokud se to někomu nelíbí, ať to nepoužívá nebo ať si udělá vlastní fork a dělá to podle vlastních představ.
2. Řekl bych, že na desktopech tato "vlastnost" velký problém představovat nebude, a na servery systemd prostě nepatří. Systemd není bezpečný by design a nikdy nemůže být. Je to důsledek toho, že Poettering neví zhola nic o zásadách návrhu spolehlivého software, spoustu věcí nechápe a proto mu připadají špatné či překonané a pokouší se je dělat jinak. Není to žádný profesionál, jako třeba Thompson či Kernighan, je to pouhý amatér, a to bez ohledu na to, na kolika projektech se podílel. Znovu opakuji, že to samo o sobě nemusí ničemu vadit, pokud to nemá sloužit na kritických místech.
Zkrátka je zbytečné se podivovat či pohoršovat nad podobnými "vlastnostmi". Systemd je amatérsky navržený kus softwaru a vše ostatní plyne z tohoto faktu. Buď to v daném nasazení nebude představovat problém, nebo by se to nemělo vůbec použít.
Pokud jde o Poetteringovo chování, tak osobně jsem toho názoru, že software se demokraticky vyvíjet nedá. On má nějaké své představy, jak by to mělo vypadat, včetně koexistence se zbytkem systému, a pokud se to někomu nelíbí, ať to nepoužívá nebo ať si udělá vlastní fork a dělá to podle vlastních představ.
Ten chlap to nedělá ve svém volnu jako koníček, ale je za to normálně placený Red Hatem. Musí přece dostávat nějaké zadání, mít nějakého šéfa. Chápu, že RH něco jako systemd potřebuje pro docker, se kterým má očividně velké plány. Ale nevěřím, že jsou v zájmu Red Hatu takové excesy, ani pro ně ten projekt nemůže být v pořádku.
Překvapuje mě, že jsem kolem afér se systemd nečetl žádný postoj Red Hatu. Přijde mi, jako by si tam LP dělal, co chce, a nikoho to nezajímalo. Je tu někdo insider, kdo by to mohl okomentovat?
Já už z toho brečím smíchy, ono to zase leakuje někde nově? :D
Když se to hlásilo, ignorovali to, tak dal jsem si do jména a příjmení text chyby PHP Nette, aby je to donutilo najít chybu. Týdny / měsíce to nikdo neopravil, místo toho u mnou zasílaných zpráviček někdo potichu ručně upravoval autora, pokud měl(i) čas/náladu/ap. Když si to všiml nějaký návštěvník a nahlásil to v diskuzi, že u nějaké zprávičky to vyhazuje chybu do textu stránky, byla reakce takováto:
https://forum.root.cz/index.php?topic=12625.msg181278#msg181278
na což jsem reagoval:
https://forum.root.cz/index.php?topic=12625.msg181289#msg181289
takže se mi začali raději začali hrabat v mém profilu a nastavili mi do jména a příjmení místo textu té chyby "ByCzech".
Naivně jsem si myslel, že si to po tomhle incidentu, když šéfredaktor vytvořil na to ticket
https://forum.root.cz/index.php?topic=12625.msg181292#msg181292
že se to prostě opraví. A koukám, že není zájem. <ironie>Ale pravda, ono to bude za 6 dnů teprve 3/4 roku, takže času dost.</ironie>
Já nevím, kde to všude leakuje, tohle mám z emailu:
Upozornění na nový názor na serveru Root.cz
ke zprávičce Bizarní chyba v systemd
Datum: 4. 7. 2017 11:51
Autor: (Opovažte se mi hrabat v mém profilu jako posledně! Místo toho opravte leakování jména a příjmení!)
Je to absurdní, protože v emailu se zobrazuje něco jiného, než je vidět v hlavičce komentáře a to se zase liší v závislosti na tom, zda je člověk přihlášený či nikoliv.
Takže já jsem pro nepřihlášené vidět jako Heron, pro přihlášené jako Tomáš Crhonek a co chodí do emailů nevím. Ve foru se to chová obráceně, nebo prostě zcela jinak (možná podle toho, zda username obsahuje číslici).
Aha, takže do emaiu. To vědí (teprve :-D ) od 10.10.2016:
https://forum.root.cz/index.php?topic=12625.msg181301#msg181301
Dobře, přeložím vám to do argumentu na úrovni: Žádné aféry kolem systemd neexistují. Systemd funguje jako spousta dalších projektů ve světě OSS, má svoje silné stránky a svoje slabé stránky, má svoje chyby, má vlastnosti, které se někomu nelíbí. Ty „aféry“ jsou nepodstatné věci, které řeší pár lidí, kteří si z nějakého důvodu vyberou nějaký software, který se jim nelíbí, a pak na něj dští oheň a síru, bez ohledu na nějaká fakta. Stále oblíbená je v tomhle Java, ve světě Linuxu to byl dříve například Network Manager a dnes jeho místo převzal systemd. Vždyť se stačí podívat na zprávičku, pod kterou diskutujeme – nafouknutá bublina o nezajímavé vlastnosti, navíc napsaná velmi nepřesně. Kdyby to nebylo systemd, zajímala by někoho zprávička, že když root zadá, že chce spustit službu pod uživatelem @#!$, je příslušná hodnota ignorována, zapíše se varování do logu a použije se výchozí nastavení? Ne, akorát by se všichni podivili, který správce může jako jméno uživatele ke spuštění služby zadat @#!$.
si z nějakého důvodu vyberou nějaký software
Ty jsi placen za počet vyvolaných flame?
zajímala by někoho zprávička, že když root zadá, že chce spustit službu pod uživatelem @#!$, je příslušná hodnota ignorována, zapíše se varování do logu a použije se výchozí nastavení?
Ne nezajímala, protože evidentně všichni rádi používáme software, který si dělá co chce a ignoruje to, co mu někdo zadá. </ironie>
Panebože. Kdyby su -c command user ignorovalo user, tak je tu naprosto stejný flame.
Resp. ne, nebyl by stejný, chyběli by tady lidi, kteří by obhajovali, že je to správné chování...
Ty jsi placen za počet vyvolaných flame?
Netušil jsem, že to, že mají nenávidět Javu, Network Manager a teď systemd ti lidé dostávají příkazem.
Ne nezajímala, protože evidentně všichni rádi používáme software, který si dělá co chce a ignoruje to, co mu někdo zadá.
Opakovaně jsem tu vysvětloval, proč se to tak chová. Kdybys napsal, že ten důvod je špatný, protože je důležitější to a to, chápal bych to. Když se ale pořád tváříš, jako bys ten důvod vůbec neznal, znamená to, že buď reaguješ na komentáře, které nečteš, nebo jsi ten důvod vzal na vědomí a pochopil, ale nehodí se ti do krámu, tak se tváříš, že neexistuje.
Panebože. Kdyby su -c command user ignorovalo user, tak je tu naprosto stejný flame.
Když si vytvořím uživatele pojmenovaného 0 s UID=1000 a spustím su -c command 0, spustí se command pod uživatelem s UID=1000. Předpokládám, že bude následovat flame, jakeje to su špatné a nebezpečné, protože nedokáže rozlišit, zda má být UID=0 nebo login=0, a že je to tedy neuvěřitelně špatný program.
A když si vytvořím uživatele #0, tak mi sudo -i -u '#0' spustí shell pod rootem. Flame může začít…
Netušil jsem, že to, že mají nenávidět Javu, Network Manager a teď systemd ti lidé dostávají příkazem.
Zvýrazňoval jsem něco jiného. Opět se dostáváme do stavu, kdy překručuješ to, co někdo píše.
Opakovaně jsem tu vysvětloval, proč se to tak chová.
To vysvětlení je asi jako když Ovčáček překrucuje to, co kde Zeman zase provedl. Ano, jistě se to dá okecat, ale otázkou je, zda se takto má navrhovat software. Za mě ne.
Ale už toho nechám. U problému s MySQL mě taky někdo přesvědčoval o tom, že je to vlastně moje chyba, že já si mám zkontrolovat, zda engine běží, zda se vytářejí table správného typu a zda se provádějí transakce. (Tedy já bych měl dělat činnost, pro kterou jsem si ten program pořídil .....) a že to, že ten software vesele ignoruje polovinu příkazů je vlastně ok. Tím dnem pro mě MySQL skončila. Program, kde jeho autoři a jeho příznivci uvažují tímto stylem, používat opravdu nechci.
Problém je, že situace se systemd je o něco horší. A to je ta zvýrazněná část, kterou ses vesele rozdhodl ignorovat. Jo, ještě že máme BSD. A vlastně díky LP za to, že systemd je nekompatibilní s BSD. Protože pokud se tam někdy někdo rozhodne něco podobného naimplementovat, tak to udělá lépe.
Zvýrazňoval jsem něco jiného. Opět se dostáváme do stavu, kdy překručuješ to, co někdo píše.
Zvýrazňoval jsi, že si ten software, který mají nenávidět, vyberou. Když si ho nevyberou, tak to asi dostanou příkazem, ne?
To vysvětlení je asi jako když Ovčáček překrucuje to, co kde Zeman zase provedl. Ano, jistě se to dá okecat, ale otázkou je, zda se takto má navrhovat software. Za mě ne.
Na tom, že se software vyrovná i s tím, co nezná, nevidím nic špatného. Webové prohlížeče ignorují neznámé tagy i atributy, neznámé HTTP hlavičky. Poštovní klienti ignorují neznámé hlavičky e-mailů. Routery ignorují neznámé rozšiřující hlavičky paketů. PKI knihovny ignorují nekritická rozšíření certifikátů. Skoro bych řekl, že kdyby se software nechoval právě takhle – že ignoruje atributy, které nezná – ještě bychom kvůli zpětné kompatibilitě používali děrné štítky.
A to je ta zvýrazněná část, kterou ses vesele rozdhodl ignorovat.
Ta zvýrazněná část byla o tom, že si někteří ten software vybrali k tomu, aby na něj nadávali. To vůbec nesouvisí s tím, jestli ho používají nebo nepoužívají.
Filip Jirsák 4. 7. 2017 16:20:
Atributy, parametry, hlavičky mají každý různou důležitost, to snad není třeba rozebírat...
Není třeba více vysvětlovat, vzájemné názory chápeme, ale mnoho místních včetně mě se nehodlá bavit o snížení bezpečnosti Linuxu výměnou za pochybnou spustitelnost. Je třeba si uvědomit, že Linux je na tom s bezpečností dobře právě proto, že se vždy snažil takovýmto situacím vyhnout. Jestli nechceme dopadnout jak ty zkurvené widle, bylo by dobré pokračovat v důslednosti.
SB, 11:51: Ano, mají různou důležitost, závisí to na konkrétním případu použití. Proto si to musí ohlídat autor toho souboru nebo dokumentu, nemůže to ohlídat software, který neví, co je jak důležité.
Linux je na tom s bezpečností dobře proto, protože jeho správci rozumí tomu, co dělají, kontrolují si svou práci a neignorují chyby a varování, která jim software vypisuje. Jestli nechceme dopadnou jako Windows, nemůžeme lidem namlouvat, že Linux může spravovat každý, že je zbytečné všímat si varování, a že stačí to nějak nabušit a spustit, a uvidí se – buď je tam nějaká vážná chyba, tak se to ani nespustí, a nebo se to spustí, protože tam žádná vážná chyba není, a pak už to dál nemusíme řešit – běží to, tak co.
@Filip Jirsák, 16:16: Ale to SB nepopírá, že admini jsou důležití a v Linuxu obvykle rozumí dobře tomu co dělají. Akorát mi a věřím, že i SB nechápeme, proč by měl SW adminovi házet klacky pod nohy tím způsobem, že když se bude nastavovat konfigurační položka, bude je nutné nastavovat vytvořením si v hlavě výpočetní algoritmus, který je stejný jako ten podivný v systemd a ještě si k tomu bude muset složitě shánět data např. o tom, jestli daný (systémový) uživatel v systému je vytvořen, místo toho, aby tyhle věci dělal počítač a v případě že to nevyhovuje, tak aby daná služba prostě a jednoduše nenastartovala, protože nastartovaná služba dává falešný pocit, že je vše v pořádku. Nanastartovaná dává jasně najevo, že něco (konfigurace) není OK.
PS: Pro všechny, kteří stojí o to, aby init system zvaný systemd spouštěl službu vždy správn pod daným uživatelem, jak si administrátor přeje (a to i v případě, že začíná číslem), tak holt položku User= vynechejte a spouštějte místo příslušné binárky skript, který nebude při vyhodnocování uživatele zatížen "podivnou magií" v algoritmu spouštění služeb, ale spustí službu slušně pod příslušným uživatelem, když existuje a když ne, tak zakřičí a odmítne službu nastartovat... Moment, neztrácí se tak náhodou jedna z výhod systemd - jednoduché unit soubory vs skripty? :-D
@ByCzech
To je totiž učebnicová ukázka toho, jak si do kódu zanést závislost, která vůbec není potřeba, vyžaduje údržbu při každé změně standartu nebo odpovídajících programů v systémech (např. useadd ...) a do budoucna jenom tak maximálně vytvoří chybu, problém nebo nějaký dohad.
@NULL, 18:30: Jj to vím, koukal jsem do kódu systemd a je tam explicitní kontrola prvního znaku, u kterého autor připouští pouze A-Z, a-z a podtržítko. Zbytek uživatele připouští i čísla a tuším pomlčku/mínus, ale už ne třeba tečku (nebrat jako 100% informaci, nemám to teď před sebou a koukal jsem na to před svátkama a momentálně mi hlava ještě odpočívá až do neděle ;-)), takže předpokládám, že problémů bude nakonec více a v případě nahlášení budou zřejmě vyřešeny stejným stylem = it's not a bug, it's the feature...
ByCzech, 18:51: Asi je to marný, ale: Když napíšu podmínku pro uživatelské jméno systemd jako regulární výraz, vypadá takhle [a-zA-Z_][-a-zA-Z0-9_]*. Když napíšu podmínku z funkce is_valid_name z shadow-utils jako regulární výraz, vypadá takhle: [a-zA-Z_][-a-zA-Z0-9_]*\$?. Nepřipadá vám to nápadně podobné? Řekl bych dokonce, že jediný rozdíl je v tom, že shadow-utils připouští na konci jména dolar, což je způsob, jakým Samba označuje účty počítačů.
Takže problémů bude samozřejmě více – budou pokaždé, když někdo vytvoří uživatele, který neodpovídá pravidlům jeho distribuce, a nebo pokaždé, když nějaká distribuce opatchuje shadow-utils a změní pravidla pro jména uživatelů, ale už neopatchuje systemd.
To, že je kód v souladu s shadow-utils z upstreamu, mi připadá v pořádku. Jinak si někdo bude stěžovat, že to v upstreamu systemd je jinak, než jak to má v shadow-utils RedHat, tak se to upraví podle RedHatu. Pak si zase někdo bude stěžovat, že Debian má jiná pravidla, tak se to upraví podle Debianu. Pak se může ozvat třeba OpenSUSE a může se to v upstreamu pořád měnit, podle toho, která distribuce se ozve jako poslední.
@Filip Jirsák, 20:10: Určitě to je marné, ale stejně to napíšu:
1. systemd není shadow-utils, je teda úplně fuk, jestli tam Poetering něco od nic opsal nebo ne = off topic
2. Jsou i jiné nástroje na vytváření uživatelů, že?
3. Portable user name má povoleno jiné znaky, takže je dementní se divit, že je možné vytvořit i uživatele, který vypadá i jinak, než Poetering chce dovolit v systemd a o tom, jak se k tomu staví je ještě horší a i kdyby se Jirsák na hlavu do kouta postavil a odrážel ušima, stejně se realita nezmění.
Po initu chci spustit službu pod daným uživatelem, uživatel v systému existuje, chci ať se pod ním spustí, to že jméno uživatele Poeteringovi nelíbí, ale třeba bude Jirsák spokojený, když ho díky jménu někam nepustí, protože Jirsák neprojde něčím co se někomu nelíbí :D
ByCzech, 17:13: Admin si nemusí žádný výpočetní algoritmus sestavovat. Úplně stačí, když použije normálního uživatele, kterého vytvořil nástroji distribuce – a distribuce, pokud patchuje nástroje pro vytváření uživatelů, opatchuje i systemd. Pokud vytvoří uživatele jinak a ještě ho pojmenuje divně, dělá to administrátor na vlastní riziko. A měl by si pak ověřit, že ví, co dělá. Pojmenovat uživatele pro systémovou službu 0day není normální – to není házení klacků pod nohy od systemd, ale od admina. Pokud se někdo rozhodne, že bude škodit skrze jednotkové soubory, má k tomu milion možností. systemd není od toho, aby admina vodil za ručičku a nedovolil mu udělat chybu. Takovým lidem do rukou nepatří. systemd je pro lidi, kteří si uvědomují, že pracují pod root em, že musí dávat pozor na to, co dělají, a svou práci kontrolovat.
Pokud má někdo pocit, že když služba nastartovala, je všechno v pořádku, ani si nezvaliduje jednotkový soubor, ani ho nezajímají varování v logu, ani si nezkontroluje stav služby po spuštění, takovému člověku nepatří do ruky root.
Překvapuje mne vaše přesvědčení, že když někdo neumí zadat uživatelské jméno do jednotkového souboru, bude umět napsat správný skript, který bezchybně přepne na zvoleného uživatele a pod ním spustí aplikaci, a když se mu to nepodaří, ukončí se s chybou tak, aby to zaznamenal systemd.
@Filip Jirsák, 20:25: Jasně, uživatel 10venca je dle specifikací validní, tak si ho založím, vepíšu do unit file a systemd tu službu spustí misto toho jako root, ale chyba je v adminovi ne v tom softu.
A pak se divte pane Jirsáku, že s váma neradi hromada lidí diskutuje, když si jako psychopat trváte na mnohokrát vyvráceném nesmyslu, jen proto, že si úmyslně vyberete jen informace, které se vám hodí - teď např. některé verze shadow-utils vs specifikace portable names pro Linux a jiné nástroje pro vytváření uživatelů. Právě proto shadow-utils některé distribuce patchují, protože to neodpovídá specifikaci. Vezmete si jen co se vám hodí a pak se kroutíte jako had, aby mohlo být po vašem. Pro mě stačilo, psal jsem už v předešlém příspěvku, že vím, že to je zbytečné - samozřejmě bylo.
ByCzech, 22:41: Úmyslně vybíráte informace vy. Zapomněl jste dodat, že jste si vybral jeden z mnoha standardů. A mimochodem, pokud jste myslel POSIX, ty patche shadow-utils naopak pravidla POSIXu vzdalují. Pokud nějaká distribuce má v různých nástrojích různá pravidla pro jména uživatelů, je to problém té distribuce, ne upstreamu. Že trváte na mnohokrát vyvráceném nesmyslu si myslím i já o vás.
@Filip Jirsák, 23:04: Přesně tuhle reakci jsem čekal. Jste hodně čitelný. Ne já si nevybral jeden, já beru v úvahu všechny. Pokud nějaký dovoluje založit uživatele 23ferda a je to OK, tak nevidím důvod, proč by místo spuštění služby pod tímto uživatelem řádně zapsaným do konfigurace měl init spouštět službu pod uživatelem root. Moje úvaha je vedena směrem "nedělej problémy", vaše a Poeteringova problémy dělá. Tož tak.
PS: Že je kontrola uživatele pomocí NAME_REGEX konfigurovatelná, ale u systemd ne také raději opomíjíte, že? Jen jste si vybral informaci, že prej shadow-utils to v mainstreamu neumí. Kecy v kleci.
Ne já si nevybral jeden, já beru v úvahu všechny.
Nemůžete brát v úvahu všechny standardy, pokud určují pojmenování jednoho jména a zároveň se liší. V takovém případě vždy existují jména, která jsou podle jednoho standardu v pořádku a podle jiného ne – jak se rozhodnete? Ať zvolíte jednu nebo druhou cestu, vždy nějaký standard porušíte.
Pokud nějaký dovoluje založit uživatele 23ferda a je to OK, tak nevidím důvod, proč by místo spuštění služby pod tímto uživatelem řádně zapsaným do konfigurace měl init spouštět službu pod uživatelem root. Moje úvaha je vedena směrem "nedělej problémy", vaše a Poeteringova problémy dělá. Tož tak.
To, že problémy nevidíte, neznamená, že neexistují. Jakmile rezignujete na to, že v tom bude nějaký systém, a místo toho budete implementovat ad-hoc případy,které někdo náhodou zadal jako chybu, bude v tom akorát chaos a bude to způsobovat jen problémy. Teď si někdo vzpomněl, že potřebuje používat jména s číslem na začátku a nutně je musí zadávat jménem. Pak si někdo jiný vzpomene, že nutně potřebuje pojmenovat uživatele @system. Někdo další přijde s tím, že má uživatele root, který nemá uid nula. A v kódu se bude vršit jeden if za druhým a místo dvou jednoduchých pravidel pro zadání uživatele se to bude zadávat metodou pokusu a omylu.
Že je kontrola uživatele pomocí NAME_REGEX konfigurovatelná, ale u systemd ne také raději opomíjíte, že? Jen jste si vybral informaci, že prej shadow-utils to v mainstreamu neumí. Kecy v kleci.
Co si zase vymýšlíte? To není odvaha, to je hloupost, bez podívání se do zdrojáku prohlásit, že je tam nějaký konfigurovatelný regulární výraz. On tam žádný regulární výraz není, testuje se to stejným způsobem, jako v systemd, tedy v cyklu se prochází jednotlivé znaky,
Nemůžete brát v úvahu všechny standardy
Nemůžu? Kdo mi to zakáže? Jirsák? Zajímavé, že jste mi před "chvílí" ještě tvrdil, že jsem si vybral jen co se mi hodí.
Vybrat si nemůžu a všechno taky nemůžu. Prostě diktátor Jirsák to určí, že? :D Jasně!
Já si s dovolením můžu vzít v úvahu všechny a zvolím cestu, která neudělá problém takový, že by dovolila spouštět službu pod rootem, přestože má spouštět pod uživatelem. Vy si volíte opak a říkáte, že je to správně.
To, že problémy nevidíte, neznamená, že neexistují
On můj přístup dělá nějaký problém srovnatelný s tím, že nastartuje něco s vyššími právy, než by mělo? A wo tom to je!
místo toho budete implementovat ad-hoc případy,které někdo náhodou zadal jako chybu, bude v tom akorát chaos
Ano, to přesně udělal Poetering v systemd, když místo kontroly, zda uživatel existuje implementoval před tímto filtr, který vyhodnocuje, jestli se mu uživatel líbí a když ne, tak se rozhodl uživatele ignorovat a spustit to pod rootem - jak říkáte, chaos.
Pak si někdo jiný vzpomene, že nutně potřebuje pojmenovat uživatele @system. Někdo další přijde s...
To už jen vaříte z vody. Úplně normálně si vymýšlíte, protože nemáte nic relevantního pro argumentaci.
Tímto způsobem se odborná diskuze vést nedá. Ale můžete zkusit jít pokecat s malými dětmi, co by kdyby třeba přiletěli ufoni udělat systemd audit :-D. Rovněž informační hodnota 0.
Co si zase vymýšlíte?
Bavili jsme se pokud mě paměť neklame o mainstreamu. Jsou distra v mainstreamu, které používají adduser.conf nebo ne? Pokud říkáte, že mluvíte o mainstreamu a přitom minimálně část mainstreamu ignorujete, je to pak s vámi vážně těžké - jak říkám, vybíráte si co se vám hodí a co se nehodí, jakože nevidíte. To je přístup úplně na houby. Přesně jak Poetering - když to nevidím/si před tím zakryju oči, tak to neexistuje :D.
Nemůžu? Kdo mi to zakáže?
Zakáže vám to logika. Když máte v jednom standardu napsáno, že jméno může začínat jenom písmenem, a v druhém standardu je, že může začínat písmenem nebo číslicí, nemůžete napsat validátor, který bude splňovat oba standardy a zároveň o kterémkoli předloženém jméno prohlásí, zda je nebo není validní.
Zajímavé, že jste mi před "chvílí" ještě tvrdil, že jsem si vybral jen co se mi hodí.
Vybrat si nemůžu a všechno taky nemůžu. Prostě diktátor Jirsák to určí, že? :D Jasně!
Kecy. Kritizoval jsem, že jste si vybral jeden standard, a tváříte se, jako že ostatní vůbec neexistují. Což je poněkud směšné, když pak kritizujete autory systemd za to, že si vybrali jeden standard, a Lennart Poettering je si vědom toho, že existují i jiné standardy, a zmínil, proč si vybral právě tenhle.
Já si s dovolením můžu vzít v úvahu všechny a zvolím cestu, která neudělá problém takový, že by dovolila spouštět službu pod rootem, přestože má spouštět pod uživatelem.
Fakt? I v případě, kdy administrátor udělá chybu? Tak sem s tím, popište, jak byste to vyřešil.
Vy si volíte opak a říkáte, že je to správně.
Já si nevolím opak. Já mám akorát trochu větší představivost, takže si dovedu představit případy, které rozbijou všechna ta navržená bezchybná řešení. Ale prosím, vy tvrdíte, že máte bezchybné řešení, které nerozhodí žádná chyba nebo zlomyslnost administrátora, tak sem s ním.
Ano, to přesně udělal Poetering v systemd, když místo kontroly, zda uživatel existuje implementoval před tímto filtr, který vyhodnocuje, jestli se mu uživatel líbí a když ne, tak se rozhodl uživatele ignorovat a spustit to pod rootem - jak říkáte, chaos.
Ne, tohle není žádné ad-hoc řešení. Vy stále nechápete, jak systemd zpracovává jednotkové soubory, že?
To už jen vaříte z vody. Úplně normálně si vymýšlíte, protože nemáte nic relevantního pro argumentaci.
Tímto způsobem se odborná diskuze vést nedá. Ale můžete zkusit jít pokecat s malými dětmi, co by kdyby třeba přiletěli ufoni udělat systemd audit :-D. Rovněž informační hodnota 0.
No výborně, konečně jste pochopil, že celý ten bugreport je nesmysl. Jeho autor vaří z vody, úplně normálně si vymyslel uživatel 0day, protože neměl nic relevantního pro argumentaci.
Bavili jsme se pokud mě paměť neklame o mainstreamu.
Paměť vás klame. Stačí, když se podíváte o pár komentářů výš, a uvidíte, že jsme se bavili o upstreamu shadow-utils. Příště si radši osvěžte paměť dřív, než na výmyslech vaší paměti začnete stavět dalekosáhlé teorie.
Ad Linux je na tom s bezpečností dobře - nechci vám brát iluze, ale čísla hovoří jinak.
https://www.cvedetails.com/top-50-products.php
https://www.cvedetails.com/top-50-products.php?year=2016
@hawran_diskuze
Co já s tím? To ty máš takových výrazů a takových způsobů plnou hlavu.
PS: No vidiš, my ostatní zase nemůžeme za to, přestože víš jak to tu (ne)odsazuje a chceš někomu něco adresovat, tak nenapíšeš komu.
Na druhou stranu takhle můžeš ponadávat kde komu, i hramadně ba dokonce i dodatečně :-)
Samozřejmě je špatně, že se direktiva "User=" parsuje jako UID i username.
Ale další problém vidím v tom, že není jasně daný formát username. Existuje ve světě Linuxu nějaká dokumentace, která by to popisovala? Asi ne, a závisí to tom, jak se vyspali autoři konkrétního distra.
Pro srovnání z MSDN: User account names are limited to 20 characters and group names are limited to 256 characters. In addition, account names cannot be terminated by a period and they cannot include commas or any of the following printable characters: ", /, \, [, ], :, |, <, >, +, =, ;, ?, *. Names also cannot include characters in the range 1-31, which are nonprintable.
No, on bude IMO vtip v tom, že jakmile zjistí že první znak je číslo, tak "zahodí" všechno co jsou písmena, bych si tipl a proto zbude 0, což je [virgl] root. Takže je možné že na "0yuppie1" by hledal uživatele 01 nebo 1. Nezkoušel jsem -nemá cenu, ať tak nebo tak je to špatně, protože nehledá "0yuppie1" ať už je to syntax. správně nebo ne.
https://www.root.cz/zpravicky/bizarni-chyba-v-systemd/#o928358
Já se na ten linkovaný "zdroj" na githubu díval už před několika dny a jediné co se tam řešilo je filozofiký přístup LP k tomu, že je to správně a není to bug, Tak nelži.
A ty ses do toho kódu díval? Dneska se k tomu asi nedostanu, ale garantuju ti že se podívám už jenom co že se tam s tím přesně děje, že se z "0day" stane "root" nebo 0.
Já nelžu. V těch komentářích je mimo jiné výslovně vyvrácena vaše domněnka, že když hodnota začíná číslem, zbytek se ignoruje. Stejně tak je tam vysvětleno, jak se systemd chová.
A ty ses do toho kódu díval?
Samozřejmě. Já nemám ve zvyku plácat v diskusích nesmysly o něčem, o čem nic nevím.
garantuju ti že se podívám už jenom co že se tam s tím přesně děje, že se z "0day" stane "root" nebo 0.
Opět, v těch komentářích na GitHubu to máte vysvětleno a je tam i komentář s odkazem na konkrétní kód. Z "0day" se nestane "root" ani "0". Prostě když má nějaká volba hodnotu, která neodpovídá syntaxi, ta volba se ignoruje, jako by tam nebyla. Systémové jednotky se spouštějí pod rootem, výjimkou je jedině případ, kdy je explicitně uvedena volba User. Takže když jí systemd ignoruje, spustí se to normálně pod rootem.
"Samozřejmě. Já nemám ve zvyku plácat v diskusích nesmysly o něčem, o čem nic nevím."
To asi ano, ale plácat nesmysly o věcech o kterých i něco víš ti většinou žádný problém nedělá.
Jinak nejsem si úplně jistý tím co se tam píše, přece kekdo kromě tebe v diskuzi plácá, takže si to pokud budu mít chuť, ověřím, ale i ten můj předpoklad klidně může být mylný. To se u předpokladů stává.
"Z "0day" se nestane "root" ani "0". Prostě když má nějaká volba hodnotu, která neodpovídá syntaxi, ta volba se ignoruje, jako by tam nebyla. "
Což je zajímavé, protože jako první je tam (podle těch tvých linků)
parse_uid(c->parameter, &id);
což moc jako kontrola syntaxe nevypadá - doměnka - nemám na to dnes čas, ale začíná mě to zajímat čím dál tím víc . . .
Ne, u čísel se to nevyhodnocuje jinak. Je to tak, jak jsem to napsal výše. systemd prostě u každé volby nejprve vyhodnotí, zda hodnota odpovídá syntaxi povolené pro danou volbu. Když hodnota té syntaxi neodpovídá, vypíše varování do logu a tu volbu kompletně ignoruje, jako kdyby v jednotkovém souboru vůbec nebyla.
Klasický Jirsákův problém s pochopením psaného textu? IMO se čísla v proměnné User chápou jako UID nikoli jako username = k číslům se systemd chová jinak, než k alfanumerickému řetězci, ke kterému se chová jako k username. To že je před tím ještě dementní Poeteringův syntakční filtr, který se primárně snaží podle <sakrasmus>fáze měsíce a pohlaví uživatele</sarkasmus> rozhodnout, jestli vůbec bude se ZADANOU konfigurační hodnotou pracovat nebo ne, na tom co jsem napsal v předchozím příspěvku nic nemění! Akorát to ukazuje na další nedostatky v návrhu. Já jen jasně napsal, že k číslu se systemd chová jinak než k NEPLATNÉ položce. Pokud vím, číslo je platná položka = zachází se s ní jinak než s neplatnou položkou, nebo ne?
Původně jste psal o čísle na začátku hodnoty, myslel jsem, že v tom pokračujete – jinak totiž váš komentář nedává smysl. K platným položkám se systemd vskutku chová jinak, než neplatným – neplatné ignoruje, platnými se řídí. Pokud je hodnotou User jen číslo, je to platná položka. Neplatná položka User je to např tehdy, když obsahuje symboly, mezery, znaky s diakritikou, nebo když začíná číslicí a není to číslo.
No vida, Jirsák umí uznat chybu? Klobouk dolů. Každopádně nechápu, jak si můžete myslet, že v tom pokračuju, když hned na začátku příspěvku píšu "to je pravda". To že vám něco nedává smysl, neznamená, že tam smysl není. Každý uvažuje jinak, ale najdou se ješitové, co to nechápou a svůj způsob cpou ostatním vrchem spodem jako jediný správný, pak je diskuze o ničem. Systemd vykazuje v daném tématu více - řekněme "zvláštností", takže se není co divit, že se o tom dá přemýšlet více "do šířky".