Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).
V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.
Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.
Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu březnový souhrn novinek. Vypíchnout lze, že pracují na virtuálním asistentu PineVox a zatím bezejmenných sluchátkách na lícní kosti (bone conduction).
Hyprland, kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, je již dva roky starý. Při té příležitosti byla vydána verze 0.37.0 (a záhy opravná 0.37.1 řešící chybu ve vykreslování oken). Nově závisí na knihovně hyprcursor, která poskytuje škálovatelné kurzory myši.
Správce systému může nastavit, pod jakým uživatelem má systemd spouštět danou službu. Pokud správce udělá chybu a zadá jméno neexistujícího uživatele, systemd službu nespustí. Pokud je jméno existujícího uživatele 0day (začíná nulou), systemd spustí službu pod právy roota. Dle Lennarta Poetteringa se o chybu systemd nejedná. Takový uživatel prý nemá na Linuxu co dělat. Nejenom v linuxové distribuci CentOS 7.3 jej ale lze normálně vytvořit [reddit].
Tiskni Sdílej:
If the username is valid but the user doesn't exist we'll let the unit fail on start. If the username is already invalid syntax-wise we'll log about it but proceed.na "invalid syntax-wise" staci vlozit tabulator, alebo neaglicky znak, alebo nieco podobne.
S nacismem nemam nic spolecneho. Nacismus jsem naopak opakovane odsoudil jako zlocinny. Jeden z mych psu potreboval operaci a kdybych nemel prostredky mu ji zaplatit, zemrel by.ChronicLame
vzdyt ani nevite, co ta distribuce obsahuje :)Jistěže nevím, co všechno ta konkrétní distribuce obsahuje za patche. Proč bych měl, když mě to bude zajímat, tak se podívám.
Jisteze, a systemd balicek tech patchu obsahuje necelou stovku (93)...Potřeba 93 patchů systemd může stejně dobře poukazovat na problémy či speciální potřeby v distribuci nebo na problémy v upstreamu.
Argumentace se vedla v rovine, ze vyrabet patch "pry" nema cenu. Opak byl nezpochybnitelne dolozen - funkcni patche se do distribuce viditelne dostavaji bez ohledu na jejich zacleneni v upstreamu.Měl jsem za to, že vedeme diskuzi o opravě systemd, ne o opravě balíčku v jedné konkrétní distribuci, takové diskuze bych neměl motivaci se zúčastnit a Michal nejspíš taky ne. Bohužel jsme oba dva očekávali jistou dávku příčetnosti, která vám podle všech indicií chybí.
Chapu, ze notoricti systemd hateri stejne budou mlit dokola to "svoje"...Klišé.
Jasne, jeste se muzeme skrabat levou rukou za pravym uchem a snazit se systemd zbavit... preju hodne stesti :)Ono ani není potřeba se ho zbavovat, stačí ho prostě s výhradami používat nebo ho nepoužívat, já osobně mám v poslední době vyzkoušeno obojí. Je tu hned několik distribucí, které umožňují systemd nepoužívat a některé dokonce umožňují vyhnout se dalším problematickým projektům.
Fakt, ze nejde pouzit uzivatele zacinajicim cislem skutecne neni pricetny duvod pro to vubec menit distribuciNevím o tom, že by tu někdo měnil distribuci, natož z uvedeného důvodu. :)
A ano, systemd resi nektere veci lepe, nez klasicky sysv (kde to kazdy poruznu bastli) - zavislosti, sandboxing...Neučte orly létat. ;)
Patch muze napsat a navrhnout k zacleneni kdokoliv.Proč by to kdokoliv dělal?
Jen nadavani a cekani, az to opravi jeden konkretni vyvojar take zrovna moc konstruktivni neni.To by platilo, kdyby se nadávalo na to, že ten vývojář nenašel čas se tomu věnovat. Tady je problém v tom, že maintainer čas našel a bude vývoj blokovat. Ne každý má koníček v posílání patchů, o kterých předem ví, že budou odmítnuty.
"0day" is not a valid username. I wonder which tool permitted you to create it in the first place.To by nemělo normálně jít? Vždyť to sežere normální useradd command.
NAME_REGEX="^[a-z][-a-z0-9_]*\$"
. (POSIX ale dovoluje číslicemi i začít a navíc přidává tečku.)
DESCRIPTION useradd is a low level utility for adding users. On Debian, administrators should usually use adduser(8) instead.
man 8 useradd. Ano, clovek si muze delat co chce, ale to je aplikovatelne kdekoliv. Pokud nechci nasledovat doporucene postupy sve distribuce, musim byt logicky pripraveny na reseni (ne vzdy osetrenych) problemu. Stejne tak vyvojar muze odmitnout nektere problemy opravovat - wont-fix flag neni nic neobvykleho u mnoha OSS projektu, neni to zadne specifikum zrovna u systemd.
1. Pro tuto chybu je úplně jedno, jestli ten uživatel existuje nebo ne. Ta služba se spustí pod rootem v obou případech, protože direktiva je vyhodnocena jako "syntakticky nevalidní" a jako taková ignorována.
2. Zkuste (aspoň sám sobě) zcela upřímně odpovědět na otázku, jestli byste si před tím, než se začalo o téhle chybě diskutovat, při spatření takového řádku okamžitě uvědomil, že jméno začínající číslicí považuje systemd za "invalid" a že se tudíž služba spustí pod rootem.
V obecne rovine neexistujici uzivatel v konfiguraci unity neimplikuje, ze se sluzba pusti pod rootem - naopak, to chybou skonci.
Podle té diskuse na githubu má check na "syntaktickou validitu" přednost. Takže je úplně jedno, jestli se vám toho uživatele podaří vytvořit a co pro to musíte nebo nemusíte obejít.
Já nemám problém si připustit, že moje odpověď na otázku, kterou jsem nastolil v bodě 2 mého předchozího komentáře, je záporná. Chápu ovšem, že pokud někdo chce za každou cenu bránit Lennarta Poetteringa a jeho šílená designová rozhodnutí, bude nejspíš tvrdit, že kdo tam ten chyták okamžitě nevidí, nemá co dělat admina.
Chápu ovšem, že pokud někdo chce za každou cenu bránit Lennarta Poetteringa a jeho šílená designová rozhodnutí, bude nejspíš tvrdit, že kdo tam ten chyták okamžitě nevidí, nemá co dělat admina.Tak hlavně nadávání adminům je v rámci systemd apologetiky už takové klišé, že to snad nemůže brát nikdo vážně. :D
Tak hlavně nadávání adminům je v rámci systemd apologetiky už takové klišé, že to snad nemůže brát nikdo vážně. :DChapu, pro prumerne adminy se to musi delat blbuvzdorne.
Invalid user/group name or numeric ID, ignoring: 0skar
systemd-analyze verify
?
systemd-analyze verify
nevolá automaticky po systemctl edit
, některý jiný software po editaci konfigu to rovnou zkontroluje), ale nepovažuji za štastný stav, kdy na straně jedné systemd umí být docela velmi hlasitý:
Job for t.service failed because the control process exited with error code. See "systemctl status t.service" and "journalctl -xe" for details.a na straně druhé jindy ignoruje nastavení User a unitu normálně spustí jako roota. Na cli ani nepípne, unita běží a pokud je ta služba hodně ukecaná do logů, tak se ten jeden řádek může velice rychle ztratit (třeba v výpisu
systemctl status sluzba
se ztratí téměř okamžitě).
Takže z hlediska admina vše běží, služba naběhla, systemd je celkem z ticha, vše je tedy v pořádku... Jen to běží jako root.
Já tohle považuju za celkem slušný náběh na průser.
Tohle chování (ignorace řádku při neznámé syntaxi) je mi docela pochopitelné a není pro volitelná nastavení která mají nějaký default nijak zvláštní.Skutečně? U programátorky bych to čekal naopak. Přiřazení hodnoty do proměnné User nemůže záležet na dané hodnotě. Obzvláště pokud se očekává string.
Spíš mě fascinuje že nedojde k opravě validního formátu uživatelského jména na to, co je možné nastavit v linuxu. Zvlášť pokud takový username povoluje i RHEL.No, to je další věc.
Listen
cosi zabrblal do logu a nastartoval s tím, že poslouchá na 0.0.0.0:80, budu to považovat za jednoznačnou chybu. Kdyby (hypoteticky) příkaz iptables při zadání syntakticky nekorektního jména interface (např. moc dlouhého) pro option -i
nebo -o
použil nějaký default (třeba lo
) nebo kdyby se choval, jako kdybych tam tu podmínku vůbec neměl, budu se do krve hádat, že tohle fakt není košer. Stejně tak spuštění služby, která měla běžet pod nějakým uživatelem, pod rootem je pro mne jednoznačně za hranicí toho, kdy je možné "podivný" parametr prostě suše nahradit defaultem a hláška do logu je dostatečná.
User
.
User
, použije se místo roota – pokud uživatel existuje (jinak se ohlásí chyba). To, co některým lidem vadí, je právě to, jaké má tohle standardní chování důsledky.
Přiřazení hodnoty do proměnné User nemůže záležet na dané hodnotě.V rade pripadu, pokud je vstupni hodnota neplatna, se pouziva defaultni hodnota. A defaultni hodnota u sluzeb je tradicne root.
Obzvláště pokud se očekává string.Dostava string.
To, že se neznámé hodnoty ignorují, je běžný postup zajišťující dopřednou kompatibilituTo je celkem dobry argument, ale osobne bych v danem kontextu presto tento pristup nepouzival, i kdyz to muze zjednodusit zivot programatorum dodavajicim unity se SW.
Spíš mě fascinuje že nedojde k opravě validního formátu uživatelského jména na to, co je možné nastavit v linuxu.Podle mne to nejde. Vždyť si do
/etc/passwd
může každý napsat, co ho napadne. Ne že by pak ke všem jménům všechny nástroje přistupovaly stejně, ale nejspíš se zase najde někdo, kdo to označí za chybu systemd… Pokud má mít systemd nějakou syntaxi pro uživatelská jména, je otázkou jenom to, jak moc neobvyklá jména má ještě povolit.
Pokud má mít systemd nějakou syntaxi pro uživatelská jména, je otázkou jenom to, jak moc neobvyklá jména má ještě povolit.To si zas otočil. Je úplne jedno aké mená bude povolovať, ale tie musia existovať v systéme, pokiaľ nie, tak sa nemá SD správať ako idiot a spustiť to pod rootom.
Chapu, pro prumerne adminy se to musi delat blbuvzdorne.Například já jsem docela podprůměrný admin. Znamená to, že systemd nemám používat na svém osobním počítači?
abc
existuje, spustí to systemd pod uživatelem abc
. Pokud neexistuje, ohlásí chybu a skončí.
Problém nastává, když se to pokusíte spustit pod něčím, co daný program neočekává jako uživatelské jméno. Pokud nějakému init skriptu předáte jméno s mezerou, dost možná skončíte se shell injection. Pokud sudo
předáte jako uživatelské jméno #0
, spustí to pod rootem.
sudo
předám jako uživatelské jméno #0
, tak se to
spustí pod root
em nikoliv proto, že to chce Lennart, ale protože to chce
uživatel. Pomocí #
se totiž nepředává uživatelské jméno, ale UID
.
Navíc celou dobu tu řešíme problém, že uživatel abc (př. 0day
) v systému existuje,
ale systemd
spustí službu pod jiným uživatelem. A to dokonce superuživatelem.
sudo
uživatel musí znát syntaxi a když si pojmenuje uživatele divně #0
, má smůlu a musí použít uid. Zatímco v případě systemd je špatně, že se po uživateli chce, aby znal syntaxi, a když si pojmenuje uživatele divně #0
nebo 0day
, je to chyba systemd. Holt když dva dělají totéž, jednou je to naprosto v pořádku, ale v druhém případě je to katastrofální chyba.
Když uživatel abc
v systému existuje, systemd spustí službu pod uživatelem abc
.
Když uživatel #0
v systému existuje, sudo
spustí příkaz pod jiným uživatelem. A to dokonce superuživatelem. Je to pořád to samé, máte stejného uživatele, sudo
i systemd se zachovají stejně, ale chyba je to jenom u systemd.
když si pojmenuje uživatele divně #0 nebo 0dayA jenom náhodou nerozlišujete, že to první jméno není platné uživatelské jméno, zatímco to druhé ano.
#0
, někde zase není platné uživatelské jméno ani 0day
. To, že zrovna na vašem systému to první není platné uživatelské jméno a to druhé je, je váš problém.
Když nějaká distribuce má pravidla na to, jak mohou vypadat uživatelská jména, měla by tomu svoje programy přizpůsobit – včetně systemd.
$ useradd \#0 $ grep \#0 /etc/passwd #0:x:1002:1002::/home/#0:/bin/sh $ userdel \#0 userdel: user '#0' does not existTestováno na Debianu.
Neexistuje žádný jediný obecný předpis, který by říkal, jak vypadá platné uživatelské jméno.Ehm... posix?
useradd
nastavené ta pravidla jinak. Hodně štěstí.
Že neexistují třeba různé linuxové distribuce, které mají v useradd nastavené ta pravidla jinak.A ta pravidla porušují posix? Třeba povolením znaku #, který posix nepovoluje? Takovou distribuci bych rád viděl.
Jak jste přišel na to, že zrovna POSIX je ta správná norma?Máte pro linuxový systém nějaký lepší návrh na tu správnou normu™?
adduser
, pak rovnou odpovídám, že jsem přesvědčen, že i takový adduser
je špatně.
Já bych to formuloval trochu obecněji. Jedna věc je, když v konkrétním případě poruší normu někdo, kdo ji dobře zná, rozumí tomu, proč konkrétní pravidlo existuje, a je tudíž schopen poznat, kdy nastala ta situace, kdy už je lepší pravidlo porušit. Jiná věc je, když někdo normu ignoruje proto, že si připadá jako velký cool frajer, který na pravidla* kašle a vykřikuje věci jako "So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"
* - tedy na ta, která si nevymyslel sám
ale je to pořád podstatně lepší, než žádná validace.Naopak, je to podstatně horší. Mít po celém systému rozeseté stovky instancí kódu, který nějak kontroluje, jestli je uživatelské jméno korektní, je principiální pitomost. Má se to pokud možno kontrolovat na jediném místě. A pro kontrolu korektnosti uživatelů, kteří mají existovat, už na UNIXu dávno takové jedno místo je: totiž knihovní funkce
getpwnam()
. Tato funkce se chová korektně, i když dostane jako parametr sebepodezřelejší string, takže efektivně uživatelská jména validuje za vás.
A jen tak mimochodem, uživatelská jména začínající číslicí nejsou nějaký obskurní výstřelek, nýbrž suchá realita: zavzpomínal jsem na všelijaké UNIXové servery, na kterých jsem za posledních 20 let měl účet, a hrubým odhadem na polovině taková jména existovala a často i dodnes existují.
getpwnam()
.
User
zadáno uid uživatele jako číslo v desítkové soustavě.
I do funkce validující formát popisující celé číslo v desítkovém pozičním zápisu se ten parametr nejdřív musí nějak dostatAno, většinou se to dělá tak, že se od někud přečte, a pak se té funkci předá. Čtení a předávání dat, pokud vím, již také vyřešeno bylo.
User
zadáno číslo v desítkové soustavě. Už jsem to psal výše.
getpwnam()
se předává jako céčkové pole znaků zakončené nulou. Takže cestou se to interpretuje minimálně dvakrát, často nejspíš nechtěně, takže to funguje právě jen proto, že se používá omezená množina znaků, se kterou to funguje, i když se to interpretuje špatně. (Což je mimochodem další chyba jednotkových souborů, protože podle mne nikde není definováno kódování, v jakém ty soubory mají být.) Řekl bych, že těm běžným programům nedělají Unicode znaky problém do té doby, dokud jsou zapsané v UTF-8. Zkuste použít UTF-16 a uvidíte, jak dopadnete, když to uživatelské jméno bude začínat nulovým bajtem.
Že by uživatelské jméno měla validovat funkce getpwnam()
je sice hezké, ale nejdřív se k ní to jméno musí bez úhony dostat.
Připadá mi jako dobrý nápad dát v takovémhle nepořádku striktní omezení na jména uživatelů, místo obvyklého spoléhání se, že to nějak dopadne, a pro jména, která tomuto striktnímu omezení nevyhoví, službu spouštět s právy superuživatele, přestože je to bezpečnostní chyba.
Mimochodem, UTF-16 umožňuje zapsat všechny znaky Unicode, používá také proměnnou délku znaku.Ano, takže má všechny nevýhody UTF-8 a žádnou z jeho výhod
má všechny nevýhody UTF-8
A nejen ty. Spíš by se dalo říct, že nepokrytí celého rozsahu Unicode je jediná nevýhoda, kterou UTF-16 nemá. Aspoň do chvíle, než si člověk vzpomene, že existují věci jako EBCDIC. :-)
UTF-8 je výhodné pro jazyky psané latinkou, Číňané nebo Japonci by na jeho výhodnost asi měli jiný názorTo je mimochodem mýtus. Opravdu málokdy lidé ukládají úplně čístý text (na kterém by v čínštině opravdy bylo UTF-16 výhodnější), častěji je to text obohacený o nějaké značky (HTML tagy, všelijaké lingvistické značkování, TeXová makra apod.) a ty jsou takřka bez výjimek v ASCII. A najednou se výhodnost UTF-16 rozplyne v hromadě nulových bytů :)
Takže cestou se to interpretuje minimálně dvakrát, často nejspíš nechtěně, takže to funguje právě jen proto, že se používá omezená množina znaků, se kterou to funguje, i když se to interpretuje špatněFunguje to hlavně proto, že se žádný program po cestě nepokouší o žádné chytračiny.
I kdyby bylo sudo taky blbě
sudo
to tak má, jinak bych to nepsal.
tak co to jako znamená?Znamená to, že to tak mají i init skripty používající sudo, které jsou alternativou k systemd – přesně jak to psal little.owl a trekker.dk.
To co tu předvádíš je „podívejte, je to taky blbě, takže je to vlastně dobře!“Ne, já pouze uvádím na pravou míru chybnou informaci, která tu zazněla, že jiné systémy na tyhle „chyby“ náchylné nejsou.
systemd
někdo spustí službu při nastavení
User=lightdm
, nespustí ji při User=lightdm0
a při zápisu User=0lightdm
se mu služba spustí
pod root
em, to si ani jeho Svatost Lennart neobhájí. Může si ucpávat uši, ve
sklepě se ukrývat, blokovat konverzace, brát si dovolenou... prostě neuteče
sudo
.
1existujicciuzivatel
, pokud byl vytvořen distribučním nástrojem, je problém v distribuci, že nemá sjednocené povolená jména uživatelů napříč různými programy.
To srovnání s autem je velmi zavádějící, protože nestačí, aby admin udělal jednu chybu, musí jich udělat v řadě několik. Nejdřív do jednotkového souboru zadá neexistujícího uživatele nebo vytvoří nebezpečně pojmenovaného uživatele (s číslicí na začátku). Pak nezvaliduje jednotkový soubor a nakonec ignoruje varování v logu.
Musí jich udělat v řadě několik.Neni problem.
vytvoří nebezpečně pojmenovaného uživateleJak ma vedet, ze je to nebezpecne jmeno? Kdyby si treba systemd usmyslel, ze spustitelne soubory nemohou zacinat cislem, budes to obhajovat stejne?
nezvaliduje jednotkový souborV zivote me nenapadlo, ze je potreba validovat jednotkovy soubor. Civilizovany system vypise chybu + se zastavi.
nakonec ignoruje varování v logu.Jestli sluzba bezi, proc by se mel divat do logu?
Jak ma vedet, ze je to nebezpecne jmeno?Třeba tak, že bude mít nějaké povědomí o linuxu obecně, bude vědět, že spousta programů má jeden parametr pro uživatelské jméno nebo uid a jméno začínající číslicí jim může dělat problém při rozlišení, zda jde o jméno nebo uid. On to není nějaký rozmar, že jména začínající číslicí jsou v linuxových utilitách zakázaná. Když to má nějaká distribuce opatchované a přidává možnost začít jméno číslicí, měla by to mít udělané pořádně a upravit to ve všech programech, které s uživatelským jménem pracují.
Kdyby si treba systemd usmyslel, ze spustitelne soubory nemohou zacinat cislem, budes to obhajovat stejne?TO, že uživatelská jména mohou začínat jen malým písmenem nebo podtržítkem, není vynález systemd, je to tak v shadow-utils. RedHat to má opatchované, povoluje na začátku i velká písmena, číslice a tečku, ve jméně dál povoluje navíc také tečku, povoluje ukončit jméno dolarem a omezuje délku jména na maximálně 32 znaků. Teda mít uživatele pojmenovaného jenom
.
, to taky musí být chuťovka. Toho by se měl nějaký sběratel CVE chytit, to musí být úplná žeň.
V zivote me nenapadlo, ze je potreba validovat jednotkovy soubor. Civilizovany system vypise chybu + se zastavi.Civilizovaný systém počítá s tím, že není jediný, kdo čte ten soubor, a že v něm tedy mohou být i informace, které nejsou pro něj a kterým prostě nerozumí. Takže vypíše varování a pokračuje dál.
Jestli sluzba bezi, proc by se mel divat do logu?To je takový celkem rozumný přístup, jak předcházet chybám – že se člověk podívá na informace, které mu program vypisuje, zda tam není něco neočekávaného, třeba nějaké varování. To, že programy vypisují informace do logů, není způsobené lobby výrobců harddisků, aby se rychle plnily disky, ale vypisují se do logů proto, že se předpokládá, že ty informace budou někomu užitečné. Takový ten vousatý vtip „– Ty kouříš? Víš že je na každé krabičce napsáno varování, že kouření může zabíjet! – Ale děvče, já jsem programátor. Mne varování nezajímají, já řeším jenom chyby,“ je myšlený jako vtip, ne jako návod. Navíc teda nevím jak vy, ale já stav služby jako první ověřuju příkazem
systemctl status <služba>
, který vypisuje i pěkně obarvené poslední řádky z logu týkající se dané služby, a pokud někdo ignoruje červené řádky v logu, je ignorant, a to, že mu nějaká služba možná běží pod rootem, i když by neměla, bude ten nejmenší problém.
kromě zastrčeného varování kdesi v některém loguCoze!? I kdyz pouzijete minimalni test 'systemctl status _sluzba_' vypise vam to na konci souvisejici logovane zaznamy. Pokud admin neoveri po nainstalovani sluzby ani jeji status, o prusvih si doslova koleduje.
systemctl status
nepoužije nebo je to dokonce natolik nepraktické, že nemá smysl se o tom vůbec bavit. Mnohdy se testuje spíše to, že služba odpovídá na dotaz než že by se pročítal každý řádek logu.
pročítal každý řádek logu.Tohle je jiz vylozene hloupa argumentace. Status zobrazi posledni relevatni radky logu a staci respektovat pravidlo, ze unita by mela startovat bez chyb, nebo s konecnym poctem *znamych* chyb.
Sorry, ale tady se neschodnem.Stane se. :)
Tohle je jiz vylozene hloupa argumentace.Nemyslím si. A dokonce si troufám z praxe říct, že věci ve světě fungují hodně jinak, než si mnozí idealisté představují, a to jsem taky svého druhu idealista, i když značně potlačený. :D
systemctl status <služba>
. Protože mne nezajímá jenom to, zda služba běží, ale také to, co si o tom myslí systemd. Snadno se dá udělat chyba, kdy systemd službu spustí, služba se přesune na pozadí a poběží dál, ale systemd si bude myslet, že se služba ukončila. I kdyby to nezpůsobilo problém hned, bude to problém později. Takže systemctl status <služba>
spouštím vždy a těch posledních 10 řádků logu tam vidím. Problém by mohl nastat v případě, kdy služba při startu hodně loguje a ten řádek s varováním se odroluje. Nicméně zrovna pokud nastavuju uživatele a capabilities, po spuštění služby to vždy kontroluju, protože jsem vycvičený ještě ze SysVinit skriptů, kde to nikdy nefungovalo na první pokus.
Třeba tak, že bude mít nějaké povědomí o linuxu obecně, bude vědět, že spousta programů má jeden parametr pro uživatelské jméno nebo uid a jméno začínající číslicí jim může dělat problém při rozlišení, zda jde o jméno nebo uid.Takze neni potreba mit povedomi o linuxu, ale o tom, ze nektere programy se chovaji divne. "0day" urcite neni uid, proto nechapu, jak si to muze splest s cislem.
TO, že uživatelská jména mohou začínat jen malým písmenem nebo podtržítkem, není vynález systemdCo je systemd do toho, jak jsou pojmenovani uzivatele? Ukol znel jasne: spustit sluzbu pod danym uzivatelem. Systemd nema co premyslet nad tim, co jsem tim myslel.
Civilizovaný systém počítá s tím, že není jediný, kdo čte ten soubor, a že v něm tedy mohou být i informace, které nejsou pro něj a kterým prostě nerozumí.Ale ta informace "User=" je urcena pro systemd a neni na nem, aby se sam rozhodl, ze tu informaci bude ignorovat a neco si domysli.
To je takový celkem rozumný přístup, jak předcházet chybám – že se člověk podívá na informace, které mu program vypisuje, zda tam není něco neočekávaného, třeba nějaké varování.Si predstavuju, jak by takovy pristup vypadal treba v SQL.
"DELETE FROM foo WHERE bar = 10"A v logu pak:
>> Column 'bar' not found. Ignoring entire expression 'bar = 10'.
Navíc teda nevím jak vy, ale já stav služby jako první ověřuju příkazem systemctl status <služba>,Tato funkce mi prijde zbytecna, protoze z vlastni zkusenosti muzu rict, ze systemd v ni velice casto lze o skutecnem stavu veci a neda se na ni spolehnout.
Ale děvče, já jsem programátor. Mne varování nezajímají, já řeším jenom chyby,“ je myšlený jako vtip, ne jako návod.Ale tohle je ve skutecnosti pristup systemd. Misto toho, aby resil chybu, ktera je (podle nej) v konfiguracni souboru, ignoruje ji vypsanim warningu.
Takze neni potreba mit povedomi o linuxu, ale o tom, ze nektere programy se chovaji divne. "0day" urcite neni uid, proto nechapu, jak si to muze splest s cislem.Třeba tak, že použije standardní C funkci
atoi
pro převod řetězce na číslo. Ano, některé programy se chovají tak divně, že používají standardní funkce.
Co je systemd do toho, jak jsou pojmenovani uzivatele? Ukol znel jasne: spustit sluzbu pod danym uzivatelem. Systemd nema co premyslet nad tim, co jsem tim myslel.Jenže žádnou volbu „spustit pod daným uživatelem“ systemd nemá. Systemd má volbu User, která má trochu komplikovanější chování (jako volba pro zadání uživatele u většiny programů).
Ale ta informace "User=" je urcena pro systemd a neni na nem, aby se sam rozhodl, ze tu informaci bude ignorovat a neco si domysli.Informace
User=0day
nemůže být určena pro systemd, protože nemá syntaxi, kterou systemd pro volbu User připouští.
Tato funkce mi prijde zbytecna, protoze z vlastni zkusenosti muzu rict, ze systemd v ni velice casto lze o skutecnem stavu veci a neda se na ni spolehnout.Sám jste popsal důvod, proč je důležité tu funkci používat. Protože popisuje stav, jak ho vidí systemd. A pokud systemd vidí něco jiného, než si myslíte, že by vidět měl, obvykle to značí podstatný problém.
Ale tohle je ve skutecnosti pristup systemd. Misto toho, aby resil chybu, ktera je (podle nej) v konfiguracni souboru, ignoruje ji vypsanim warningu.Už jsem vysvětloval asi milionkrát, proč se používá tenhle přístup, kdy se ignorují neznámé věci. Že to stále nechápete nebo odmítáte pochopit není můj problém.
Informace User=0day nemůže být určena pro systemd, protože nemá syntaxi, kterou systemd pro volbu User připouští.Pokud není informace
User=0day
určena pro systemd
, tak má nahlásit chybu a příkaz ukončit. Po počítači požaduji, aby dělal to co JÁ chci. Pokud jsem blbý, že ten nástroj neumím použít, tak to chci vědět. Ale hlavně ať se to nesnaží něco domýšlet.
Protože v jiném případě bude nutné do bootovacích hlášek přidat podobně jako na krabičky cigaret upozornění, že dlouhodobé používání systemd
může zabíjet.
Třeba tak, že použije standardní C funkci atoi pro převod řetězce na čísloJe mi uplne jedno (a melo by mi to byt jedno), co dany program pouziva pro konverzi cisla. Nechapu, proc se na jednu stranu program snazi testovat, jestli je navstupu validni jmeno a na druhou stranu se neobtezuje testovat, zda je navstupu platne cislo a hned to posle do funkce na konverzi hodnot.
Systemd má volbu User, která má trochu komplikovanější chování (jako volba pro zadání uživatele u většiny programů).Timhle se da zduvodnit cokoliv. I to, kdyz mi nejaka kombinace User= smaze pulku disku. Ale neznamena to, ze je to spravne chovani. Narusuje to princip nejmensiho prekvapeni.
Informace User=0day nemůže být určena pro systemd, protože nemá syntaxi, kterou systemd pro volbu User připouští.Co udela programovaci jazyk, kdyz narazi na syntaktickou chybu. Ignoruje dany radek nebo zastavi preklad?
A pokud systemd vidí něco jiného, než si myslíte, že by vidět měl, obvykle to značí podstatný problém.Takze je to dalsi vec navic, kterou musim resit. Na jedne strane si musim sam otestovat, jestli sluzba opravdu bezi spravne. A ke vsemu si musim otestovat, jestli to systemd vidi spravne. To usetri spoustu prace.
Už jsem vysvětloval asi milionkrát, proč se používá tenhle přístup, kdy se ignorují neznámé věci.Kdyz budes milionkrat opakovat jednu vec, neznamena to, ze to bude dobry napad nebo snad spravne reseni.
Je mi uplne jedno (a melo by mi to byt jedno), co dany program pouziva pro konverzi cisla. Nechapu, proc se na jednu stranu program snazi testovat, jestli je navstupu validni jmeno a na druhou stranu se neobtezuje testovat, zda je navstupu platne cislo a hned to posle do funkce na konverzi hodnot.Ptal jste se na „některé programy“, tak jsem psal o některých programech. Systemd to takhle nedělá, pokud je zadané uid, musí to být jen číslo.
Ale neznamena to, ze je to spravne chovani.A jaké je teda správné chování?
Co udela programovaci jazyk, kdyz narazi na syntaktickou chybu. Ignoruje dany radek nebo zastavi preklad?Programovací jazyk nedělá nic. Když na syntaktickou chybu narazí kompilátor, skončí překlad. Jenže ten zdrojový kód má speciální sekce, kam je možné „schovat“ části, které nejsou určené pro daný kompilátor – třeba makra nebo komentáře. Jednotkové soubory nemají žádné podmíněné části – předpokládá se, že části, kterým daný program nerozumí, prostě přeskočí. Funguje to tak u XDG souborů, které inspirovaly jednotkové soubory, a funguje to tak i u Windows ini souborů, které zase byly inspirací pro XDG. Prostě jsou ty formáty nadefinované jako rozšiřitelné, protože se počítalo s tím, že se do nich mohou přidávat další vlastnosti a mohou je zpracovávat různé programy. A také to tak funguje.
Kdyz budes milionkrat opakovat jednu vec, neznamena to, ze to bude dobry napad nebo snad spravne reseni.Já to opakuju milionkrát proto, že jsou tu stále někteří natvrdlí jedinci, kteří to stále nevzali na vědomí a pořád dokola se ptají, proč ten formát souboru vypadá právě takhle. Až to vezmete na vědomí, můžete zkuset vymyslet nějaký argument, proč je podle vás rozšiřitelný formát souboru špatné řešení. A jak byste to řešil jinak, aby jeden jednotkový soubor mohlo zpracovávat víc různých aplikací, které o sobě navzájem vůbec nemusí vědět.
Ptal jste se na „některé programy“, tak jsem psal o některých programech. Systemd to takhle nedělá, pokud je zadané uid, musí to být jen číslo.Sorry, uz jsem se v tom zamotal, kde se pouziva ta bezchybna logika "prvni-znak-je-cislo-tak-je-to-cele-cislo(tm)".
A jaké je teda správné chování?Nic neprovest a zahlasit chybu.
Programovací jazyk nedělá nic. Když na syntaktickou chybu narazí kompilátorA co kdyz na to narazi interpreter? Hele, jestli nerozumis zkratce a chces se hnipat v detailech, uvedom si, ze makra jsou urcena pro preprocesor a kompilator s nimi neprijde do styku. Ale spravne si poznamenal, ze prekladac se zastavi.
Jenže ten zdrojový kód má speciální sekce, kam je možné „schovat“ části, které nejsou určené pro daný kompilátor – třeba makra nebo komentáře.Tak proc je nema jednotkovy soubor?
Já to opakuju milionkrát proto, že jsou tu stále někteří natvrdlí jedinci, kteří to stále nevzali na vědomí a pořád dokola se ptají, proč ten formát souboru vypadá právě takhle.Mozna je to tim, ze ti jedinci nad tim premysli a nesnazi se za kazdou cenu hrat dablova advokata. Ja vubec nemam problem s tim, ze je ten format rozsiritelny. Je to klasicky soubor s daty typu klic-hodnota. A pokud nejaka aplikace dany klic nezna, je uplne kosher jej ignorovat. Je ale nelogicke, ze dana aplikace ignoruje cely par, kdyz nezna hodnotu. To totiz neni kosher, protoze ta aplikace vi, ze je v tom jednotkovem souboru chyba, a nic s tim nedela. Toto s doprednou kompatibilitou nema nic spolecneho. Proto je tvuj milionkrat opakovany argument nevalidni.
Tak proc je nema jednotkovy soubor?Asi to měl být jednoduchý formát.
Mozna je to tim, ze ti jedinci nad tim premysliTo je docela smutné, pokud výsledek přemýšlení je neodlišitelný od situace, kdy dotyčný tu věc vůbec nevzal na vědomí.
Ja vubec nemam problem s tim, ze je ten format rozsiritelny. Je to klasicky soubor s daty typu klic-hodnota. A pokud nejaka aplikace dany klic nezna, je uplne kosher jej ignorovat. Je ale nelogicke, ze dana aplikace ignoruje cely par, kdyz nezna hodnotu.Když nezná formát hodnoty, je to stejný případ, jako když nezná klíč. Prostě je to hodnota, kterou může použít nějaká jiná aplikace.
To totiz neni kosher, protoze ta aplikace vi, ze je v tom jednotkovem souboru chyba, a nic s tim nedela.Ne, neví. V tom jednotkovém souboru žádná chyba být nemusí.
0day
číselnou konstantu v desítkové, šestnáctkové, dvojkové nebo osmičkové soustavě?User
může akceptovat hodnoty různých typů a významů? Nebylo by lepší zavést více různých voleb, každou s jednoznačným významem?Reprezentuje řetězec 0day číselnou konstantu v desítkové, šestnáctkové, dvojkové nebo osmičkové soustavě?Ani jedno. Jak jste přišel na to, že to musí být číslo?
Je v pořádku ignorovat volbu, jejíž význam znám, a nerozumím pouze její hodnotě? Zde argument o dopředné kompatibilitě není validní vůbec.Jak to, že není validní? Máte třeba volbu
ExecStartPre
, která provede zadaný příkaz před startem služby. Pak přidáte další formát položky – když před příkaz přidáte mínus, nevadí když ten příkaz skončí chybou. Starší aplikace, které ten formát neznají, budou s novým formátem pořád dál pracovat – prostě tu volbu přeskočí. Co jiného by měla být dopředná kompatibilita?
Je moudré realizovat dopřednou kompatibilitu tím způsobem, že jsou neznámé volby ignorovány?Jak byste to chtěl udělat jinak?
Proč by měl systemd spustit službu, která byla určena pro novější verzi systemd a používá volby, které starší verze systemd nerozumí?Proč jen systemd? Jednotkové soubory může používat jakákoli aplikace. Třeba správce clusteru použije informace z jednotkového souboru pro distribuci aplikace na jednotlivé uzly, a systemd pak použije stejný soubor pro spuštění služby na daném uzlu.
Je moudré prostě doufat, že to nějak bude fungovat, když se nějaké volby – které tam autor asi nepoužil bezdůvodně – prostě ignorují?To přece ví autor té jednotky, kde všude se s ní bude pracovat, a musí ji tomu přizpůsobit.
Je moudré rozhodnutí, že volba User může akceptovat hodnoty různých typů a významů? Nebylo by lepší zavést více různých voleb, každou s jednoznačným významem?Systemd prostě používá takovýhle formát souboru. Mně se ten formát nelíbí, ale ještě horší by mi připadalo zavádět nějaké ad-hoc výjimky pokaždé, když si někdo usmyslí, že je něco chyba.
Ani jedno. Jak jste přišel na to, že to musí být číslo?Nepřišel. Já
0day
považuji za jméno uživatele, ale systemd nikoliv, třebaže mu validace uživatelských jmen nenáleží (SRP).
Starší aplikace, které ten formát neznají, budou s novým formátem pořád dál pracovat – prostě tu volbu přeskočí.A ten příkaz vůbec nespustí. To je úžasná „kompatibilita“.
Jak byste to chtěl udělat jinak?V jednotkovém souboru by byla uvedena verze. Implementace takovou verzi buď podporuje a vyhodnotí ji, nebo ji nepodporuje a okamžitě skončí s chybou.
Proč jen systemd? Jednotkové soubory může používat jakákoli aplikace. Třeba správce clusteru použije informace z jednotkového souboru pro distribuci aplikace na jednotlivé uzly, a systemd pak použije stejný soubor pro spuštění služby na daném uzlu.Stěží hledám relevanci s mým dotazem, který zněl:
Proč by měl systemd spustit službu, která byla určena pro novější verzi systemd a používá volby, které starší verze systemd nerozumí?
To přece ví autor té jednotky, kde všude se s ní bude pracovat, a musí ji tomu přizpůsobit.A distribuce aplikací/balíčků pro Linux je opět o krok složitější. Gratuluji. Uživatel se starší verzí systemd si nainstaluje balík. Služba se nastartuje, ale některé volby ignoruje, protože jim nerozumí. Paráda. A je to jeho chyba, protože kdyby to nebyl podřadný uživatel, měl by svou verzi systemd pečlivě nastudovanou a přesně věděl, jestli je ten soubor validní. Hmm... A že se služby občas nastartují hned po instalaci? To taky nevadí. Správní uživatelé si obsah balíků pečlivě nastudují ještě před instalací. Vinu zde nese podřadný programátor neznalý softwarového inženýrství, ne uživatel.
Systemd prostě používá takovýhle formát souboru. Mně se ten formát nelíbí, ale ještě horší by mi připadalo zavádět nějaké ad-hoc výjimky pokaždé, když si někdo usmyslí, že je něco chyba.Ten formát si zvolil oni a fakt, že ho neumí ani správně použít, je o to smutnější. Tohle není žádná ad-hoc výjimka. Prostě
User
by akceptoval jméno uživatele, UserID
by akceptovalo UID, a není potřeba to „chytře“ větvit (protože to očividně ani neumí rozvětvit správně). Teď už je pozdě to měnit, ale opět to vypovídá něco o (ne)schopnosti vývojářů.
A ten příkaz vůbec nespustí. To je úžasná „kompatibilita“.Ano, tohle je přesně to, co se označuje za dopřednou kompatibilitu. Když starší verze programu danou věc zná úplně stejně jako novější verze, není potřeba mluvit o nějaké kompatibilitě, protože ty verze jsou stejné.
V jednotkovém souboru by byla uvedena verze. Implementace takovou verzi buď podporuje a vyhodnotí ji, nebo ji nepodporuje a okamžitě skončí s chybou.Verze formátu souboru? A když já budu chtít do jednotkového souboru něco přidat pro svou aplikaci, budu muset požádat o změnu formátu, vydání nové verze specifikace, až všechny programy na mém systému budou novou verzi podporovat, a pak to můžu začít používat. Opravdu si myslíte, že by to fungovalo?
Stěží hledám relevanci s mým dotazem, který znělJá jsem nepřišel na to, proč jste dotaz omezil na různé verze systemd.
A distribuce aplikací/balíčků pro Linux je opět o krok složitější. Gratuluji.Pořád je to tisíckrát jednodušší, než váš systém.
Vinu zde nese podřadný programátor neznalý softwarového inženýrství, ne uživatel.Vtipné je, když tohle napíše člověk, který navrhne dva způsoby řešení – jeden tak komplikovaný, že je v praxi nepoužitelný, a druhý, který by se choval úplně stejně, jako se to chová dnes.
Tohle není žádná ad-hoc výjimka. Prostě User by akceptoval jméno uživatele, UserID by akceptovalo UIDJe to ah-hoc výjimka, protože všude jinde v jednotkových souborech se jedna věc nastavuje jednou volbou, a různé způsoby nastavení téže věci se řeší různou syntaxí hodnoty. Navíc by to současnou situaci nijak neřešilo, protože byste zadal
User=0day
, systemd by to vyhodnotil jako neplatnou syntaxi a volbu by ignoroval. Chovalo by se to tedy úplně stejně, jako dnes. Moc jste to nevylepšil.
Navíc by to současnou situaci nijak neřešilo, protože byste zadal User=0day, systemd by to vyhodnotil jako neplatnou syntaxi a volbu by ignoroval. Chovalo by se to tedy úplně stejně, jako dnes.
Jen by pak výmluva na to, že "by se to mohlo plést s číselným UID" zněla ještě hloupěji než teď.
Ano, tohle je přesně to, co se označuje za dopřednou kompatibilitu.Tak taková kompatibilita je určitě hodně užitečná.
A když já budu chtít do jednotkového souboru něco přidat pro svou aplikaci, budu muset požádat o změnu formátu, vydání nové verze specifikace, až všechny programy na mém systému budou novou verzi podporovat, a pak to můžu začít používat. Opravdu si myslíte, že by to fungovalo?Ano, myslím, a kdybyste se nad tím na chvíli zamyslel, myslel byste si to taky. Pokud je reálným use-casem to, že do jednotkových souborů se přídavají informace pro jiný software než systemd (což si vůbec nejsem jistý, že je dobrý nápad, ale dejme tomu), není nic prostšího než zavést speciální sekci, do které lze vložit libovolný syntakticky validní obsah, a celou tu sekci na straně systemd zcela ignorovat. V opačném případě se může stát, že dojde ke kolizi, a budoucí verze systemd začne interpretovat řádek, který tam administrátor/developer přidal pro úplně jiný software. Asi není potřeba říkat, že interpretovat takový obsah může mít ničivé následky (a opět – opravdu má být zodpovědností uživatele to velmi striktně kontrolovat na vlastní zodpovědnost?).
Já jsem nepřišel na to, proč jste dotaz omezil na různé verze systemd.Protože řeč je primárně o systemd a že někomu přijde jako dobrý nápad mixovat do jednotkových souborů nějaká náhodná data je už spíš jeho problém. Opět nezkušenost a ignorance na straně vývojářů (a obhájců).
Pořád je to tisíckrát jednodušší, než váš systém.Tak určitě. Pokud to někomu přijde hrozně moc složité, zcela určitě by neměl vyvíjet mission-critical software.
Je to ah-hoc výjimka, protože všude jinde v jednotkových souborech se jedna věc nastavuje jednou volbou, a různé způsoby nastavení téže věci se řeší různou syntaxí hodnoty.Pak je to všude jinde také špatně. To není argument, jen potvrzení, že jsem měl pravdu, když jsem tvrdil, že autoři ten svůj stupidní formát neumí ani správně použít.
Navíc by to současnou situaci nijak neřešilo, protože byste zadal User=0day, systemd by to vyhodnotil jako neplatnou syntaxi a volbu by ignoroval. Chovalo by se to tedy úplně stejně, jako dnes.Když mluvím o tom, že je to špatně už architektonicky o několik úrovní výše, fakt nepovažuju za podstatné se zaobírat tím, že Lennart někde posral pár ifů a neumí naparsovat jednoduchý řádek. Ale odpovídat byla stejně ztráta času, protože bláznům se nemá odporovat...
Ano, myslím, a kdybyste se nad tím na chvíli zamyslel, myslel byste si to taky. Pokud je reálným use-casem to, že do jednotkových souborů se přídavají informace pro jiný software než systemd (což si vůbec nejsem jistý, že je dobrý nápad, ale dejme tomu), není nic prostšího než zavést speciální sekci, do které lze vložit libovolný syntakticky validní obsah, a celou tu sekci na straně systemd zcela ignorovat.Já jsem se nad tím zamyslel už dávno, a promyslel jsem si to až do konce. Zkuste to taky, místo zamyšlení na chvíli. Princip souborů, které interpretují různé programy, není v tom, že tam každý program bude mít svou sekci a o zbytek se nebude starat – to by ten společný soubor byl k ničemu. Princip spočívá naopak v tom, že tam je každý údaj zadaný jenom jednou, a každý program si vybere ty údaje, které potřebuje. Když máte třeba
.desktop
soubor (který byl inspirací pro jednotkové soubory), asi nechcete mít tam pro každé DE zvlášť název, popis, ikonu, spouštěcí příkaz – princip toho souboru je právě v tom, že je to tam napsané jednou, a každé DE použije to, čemu rozumí.
V opačném případě se může stát, že dojde ke kolizi, a budoucí verze systemd začne interpretovat řádek, který tam administrátor/developer přidal pro úplně jiný software.K tomu by mohlo dojít, pokud by se to dělalo tím vaším způsobem – že by to byly volby pro software. Jenže ony jsou to volby popisující nějakou jednotku (službu, časovač apod.).
opravdu má být zodpovědností uživatele to velmi striktně kontrolovat na vlastní zodpovědnost?Pořád jednodušší zkontrolovat jednotkový soubor, než kontrolovat shell skript…
Protože řeč je primárně o systemd a že někomu přijde jako dobrý nápad mixovat do jednotkových souborů nějaká náhodná data je už spíš jeho problém.To je váš problém že chcete uzavírat jednotkové soubory do jednoho jediného software. Vývojáři systemd dělají systém otevřený, aby se ty stejné jednotkové soubory daly použít i pro jiné aplikace, třeba pro jiné správce služeb.
Asi to měl být jednoduchý formát.A je to tedy jednoduchy format, kdyz k jeho pouzivani clovek musi znat nejen syntaxi, semantiku voleb, ale mit jeste dalsi tezko definovatelny "background knowledge"?
Když nezná formát hodnoty, je to stejný případ, jako když nezná klíč. Prostě je to hodnota, kterou může použít nějaká jiná aplikace.Ne, neni. Takto se dopredne/zpetne kompatibilni format/rozhrani nenavrhuje.
V tom jednotkovém souboru žádná chyba být nemusí.Ale v tom jednotkovem souboru ta chyba je. Proc by ji tedy ignoroval, kdyz se v danem klici objevila neznama hodnota? Prosim neodpovidej na me otazky, jsou jen retoricke.
Takto se dopredne/zpetne kompatibilni format/rozhrani nenavrhuje.Jak se tedy navrhuje?
Ale v tom jednotkovem souboru ta chyba je.Když budu chtít spustit Apache a místo toho spustím
rm -r /*
, je v om jednotkovém souboru taky chyba. Ale není to nic, co by mohla jakákoli aplikace zjistit.
Proc by ji tedy ignoroval, kdyz se v danem klici objevila neznama hodnota?To, že je v klíči hodnota, které systemd nerozumí, neznamená, že je to chybná hodnota.
To, že je v klíči hodnota, které systemd nerozumí, neznamená, že je to chybná hodnota.
Třeba tak, že použije standardní C funkci atoi pro převod řetězce na číslo.Pokud někdo takovouhle funkci používá pro zjištění, zda řetězec je číslem, pak je s prominutím osel ušatý.
Jak ma vedet, ze je to nebezpecne jmeno?Na to existuji jiz roky zavedene konvence, vcetne znalosti moznych problemu - viz treba prezentace zde - ktera jen vicemene opakuje jen to co jsem slysel jiz v 90.letech.
sudo
jako systemd na první pokus nechová? Jakou konfiguraci máte přesně namysli, kde zadám 0day a on to pochopí jako root?
$ sudo -i -u 0day sudo: unknown user: 0day sudo: unable to initialize policy plugin
#0
a spustím sudo -i -u '#0'
.
Nejdřív do jednotkového souboru zadá neexistujícího uživateleNebo existujícího, na tom nezáleží, navíc to nemusí být nutně chyba, pořadí akcí v tomto případě podle mě není závazné.
nebo vytvoří nebezpečně pojmenovaného uživatele (s číslicí na začátku).Dokonce ho ani nemusí vytvořit, navíc by to pojmenování nebylo nebezpečné nebýt zcela konkrétních chyb ve zpracování vstupů ve zcela konkrétním software.
Pak nezvaliduje jednotkový soubor a nakonec ignoruje varování v logu.Jasně, všechno svedeme na admina, a teď zpátky do reality a pojďme tvořit software, jehož bezpečnost není primárně řešena přečtením konkrétního řádku logu v době, kdy už je pozdě. Tyhle výmluvy jsou naprosto směšné. Já bych viděl postup slušného open source vývojáře asi takto: 1) Napíšu kód, který se laxně chová ke vstupu. 2) Dostanu hlášení chyby a někdo tvrdí, že to může mít vliv na bezpečnost. 3a) Opravím laxní chování ke vstupu na striktní a pokud to na mě nepůsobí jako zásadní bezpečnostní chyba, tak to dál neřeším a zbytek přenechám jiným, protože nejsem bůh a nemusím řešit všechno. 3b) Napíšu, že nemám čas se tomu věnovat a že patches welcome a podle potřeby přidám další informace. Ono někdy prostě stačí nebýt hovado s přebujelým egem.
bezpečnost není primárně řešena přečtením konkrétního řádku logu v době, kdy už je pozděNejvíc mne na tomhle případu fascinuje, jak taková prkotina dokázala přesvědčit všechny bývalé odpůrce systemd, že je to vlastně mnohem lepší řešení a SysVinit skripty jsou neuvěřitelná bezpečnostní díra. Protože když je pozdě to, že správce spustil jednotkový soubor, který nečetl nebo ve kterém přehlédl chybu, nespustil validaci a pak se mu spustila služba nečekaně pod rootem, není to nic proti tomu, když správce spustí SysVinit skript, který nečetl nebo v něm přehlédl chybu, validaci udělat ani nemohl a pod právy roota to běží daleko dřív, než dojde k případnému spuštění služby. Těší mne, že tenhle případ o tolik pozvedl nároky, které mají správci na správce služeb, a že od teď se něčeho tak nebezpečného jako SysVinit skriptů nedotknou ani násadou od koštěte.
Nejvíc mne na tomhle případu fascinuje, jak taková prkotina dokázala přesvědčit všechny bývalé odpůrce systemd, že je to vlastně mnohem lepší řešení a SysVinit skripty jsou neuvěřitelná bezpečnostní díra.WTF? Normálně s vámi jenom nesouhlasím, ale dneska vás ani nechápu. :D
1) Napíšu kód, který se laxně chová ke vstupu.Systemd validuje syntaxi nastaveni a pokud neni korektni, nastavemi ignoruje a pouzije defaultni hodnoty. Tohle bych neoznacil za laxni.
2) Dostanu hlášení chyby a někdo tvrdí, že to může mít vliv na bezpečnost.V okamziku, kdy se jedna o zamyslene chovani plne pod kontrolou administratora, bych to jako chybu neoznacoval. Je to jeho design decision a neni to jediny SW, ktery to takto dela.
Systemd validuje syntaxi nastaveni a pokud neni korektni, nastavemi ignoruje a pouzije defaultni hodnoty. Tohle bych neoznacil za laxni.Já bych to naopak označil za jeden z nejtypičtějších příkladů.
man 5 passwd
) a všichni se podle ní mají řídit.
Pokud nějaký program neakceptuje nějaké jméno povolené jak POSIXem, tak místní dokumentací, je tento program prostě rozbitý a basta fidli. Ne aby si jeho autor vyskakoval, že mu zrovna takové nebo makové jméno bůhvíproč připadá nebezpečné, neestetické nebo pobuřující. Do toho s prominutím nemá co mluvit.
To, že nějakého uživatele odmítne založit adduser
, je chabá výmluva. Takový adduser
není standard, je to jen jeden z mnoha existujících způsobů zakládání uživatelů. Úplně stejně legitimní je třeba založit uživatele pomocí vi /etc/passwd /etc/shadow
. A dokud takový ručně založený uživatel bude splňovat všechny náležitosti dané normou, tak s ním mají všechny programy umět zacházet.
(Dobrá, musíme přiznat, že existují výjimky. Typicky tam, kde se setkáváme s okolním světem. Třeba MTA nejspíš má právo být trochu vybíravý v tom, jak pojmenovaným uživatelům dokáže doručovat poštu. Ale nevím o smysluplné výjimce, která by se týkala uživatelů začínajících číslicí.)
Problém nastává, když se to pokusíte spustit pod něčím, co daný program neočekává jako uživatelské jméno.Vaše imaginární problémy nikoho nezajímají - ukažte nějaký konkrétní program, který něco takového dělá.
Pokud nějakému init skriptu předáte jméno s mezerou, dost možná skončíte se shell injection.Což je chyba toho skriptu a je potřeba ji opravit. Když odhlédnu od toho, že takové jméno není platné - narozdíl od 0day
Pokud sudo předáte jako uživatelské jméno #0, spustí to pod rootem.Což je v pořádku, protože udělá přesně to, o co jste ho požádal. Na druhou stranu když sudo předám jako uživatelské jméno 0day, tak
# sudo -u 0day whoami 0dayTo je taky v pořádku - vyhovuje to mému tvrzení, že program byl spuštěn pod tím uživatelem, kterého jsem chtěl, nebo vůbec.
vim /etc/passwd
žádný NAME_REGEX nekontroluje
Chápete to úplně špatně. Řešením není udělat vim součástí systemd, protože pak zlovolný uživatel použie emacs/nano/pico/whatever. Řešení v duchu systemd je prohlásit klasickou lokální databázi uživatelů za přežitek a místo ní zavést systemd-userdbd nebo něco takového. Ten pak postupem času nahradí i PAM a NSS.
(Ne, nebojím se, že si to tu někdo přečte a systemd klice to navrhne. Spíš předpokládám, že už to tak jako tak nějakou dobu plánují. It's inevitable, Mr. Anderson.)
vim /dev/sda1
nekontroluje, že zapsaná data jsou platný formát souborového systému. Je chyba souborového systému, že pak bude číst blbosti nebo i spadne?
Pokud driver filesystému při čtení nekorektních (meta)dat spadne, je to všeobecně považováno za chybu a je snaha takovou chybu opravit. Ne že by se to nestávalo, ale nevzpomínám si, že by na takový bugreport vývojář nebo dokonce maintainer filesystému reagoval ve stylu "no a co, náš driver tohle nevytvořil, takže naše chyba to není, můžete si za to sami". A i kdyby snad ano, tak přesně tohle by byl ten typ průšvihu, za který by si vysloužil dávku toho již zmiňovaného Linusova jadrného slovníku (a naprostým právem). Navíc od té doby, co desktopová prostředí ochotně mountují všechno, co se mihne kolem, je pád driveru filesystému kvůli nekorektnímu obsahu zařízení obvykle považován i za chybu bezpečnostní, protože partition s šikovně připraveným nekorektním filesystémem si může vytvořit a přinést kdokoli s fyzickým přístupem k počítači.
A to je celé jádro problému: Lennart Poettering vyvíjí a "maintainuje" něco, co je jednou z nejzákladnějších komponent operačního systému, ale jeho přístup a (ne)zodpovědnost jsou na úrovni vývojářů webových aplikací. Bohužel není mezi lidmi kolem systemd sám, třeba Kay Sievers má v tomto ohledu ještě horší pověst. Právě tohle je ten hlavní problém systemd, ale přestože na to "potížisté" upozorňovali od samého počátku, manažeři distribucí situaci hrubě podcenili a my všichni za to teď neseme následky. A ještě dlouho asi bohužel poneseme.
Zkoušel jste to? Na to, aby "četl velmi podivné věci", budou muset ta metadata poškozená dost šikovně, rozhodně ne nějakým "vim /dev/sda1
", jak jste psal.
Tady je ovšem problém v kombinaci tří faktorů:
To první je problematické, ale dalo by se s tím žít. To druhé je bezpečnostní chyba. Nejhorší je ale to třetí, protože to v plné nahotě ukazuje myšlení lidí, kteří za systemd stojí.
Pokud chcete skutečně tvrdit, že se ext3 chová jako systemd, pak vás prosím o konkrétní případ toho, kdy driver ext3 filesystému na základě nevalidních metadat nějakému neprivilegovanému procesu umožní buď běžet s EUID 0 nebo aspoň provést operaci, na kterou nemá mít nárok. Ale pozor, navíc nestačí, aby se taková chyba vyskytla, ale aby po jejím nareportování byla vývojáři/maintainery kódu odmítnuta s tím, že se o chybu nejedná. Teprve pak budu ochoten uznat, že ext3 se chová jako systemd.
On se do toho nesere - on vyhodi chybu do logu a proste to pusti pod rootem.Technicky vzato nevyhodí chybu, ale varování, navíc ne zrovna vysvětlující situaci.
User
a UserID
), přičemž jedna akceptuje liboovolný string a druhá akceptuje libovolné číslo (decimální, hexadecimální, nebo jaké chtějí). Mimochodem, zda je technicky možné v syntaxi, kterou si systemd zvolil (tj. obdoba *.ini
souboroů), zapsat opravdu zcela libovolný string si nejsem tak jistý a opět to poukazuje pouze na jejich blbost. Programují systemd, nebo parser konfiguračních souborů? Co jim bránilo použit XML, JSON, YAML, nebo cokoliv jiného?
Druhá rovina je, že ignorovat volbu, jejíž význam znám a pouze nerozumím hodnotě, je chybné chování. Pokud chtějí kvůli dopředné kompatibilitě ignorovat volby, jejichž význam neznají, budiž – nemyslím si, že je to dobrý nápad, protože soubory jsou očividně mířené vůči nějaké konkrétní verzi systemd a autor tam daný řádek neumístil náhodou. Tiše jej přejít a doufat, že to bude fungovat zrovna tak dobře, je zhovadilost. Pokud už to tak ale opravdu musí být, stále to neospravedlňuje, aby systemd ignoroval i volbu, jejíž význam (jméno) zná, ale nerozumí pouze její hodnotě. Mělo to prostě chcípnout s chybou.
Hotovo. Tečka.
Pokud se to tady někdo snaží obhajovat a ještě se ohání tím, kdo je nebo není dobrý admin, měl by se zamyslet především nad svými vlastními schopnostmi, protože tohle může obhajovat jen naprostý diletant.
proximity:~ misacek$ ssh -L 34590345935:localhost:59000 server.com Bad local forwarding specification '34590345935:localhost:59000' proximity:~ misacek$ head -0sadifujs file.txt head: illegal line count -- 0sadifujsMěl bych snad čekat, že si SSH „ten správnej“ port domyslí? Nebo použije nějakej default? WTF? Ta druhá legrace s ignorováním neplatné direktivy je taky dobrá sranda (viz příklad s
Usr=
). No kde jsme?
proximity:~ misacek$ du -omg du: illegal option -- o usage: du [-H | -L | -P] [-a | -s | -d depth] [-c] [-h | -k | -m | -g] [-x] [-I mask] [file ...]Vzhledem k tomu, jak může parametr měnit výstupy byť nějaké blbé utility, je zřejmý, že kdyby se to nevydrbalo, může to skončit něčím, co vůbec nechci. To jako fakt budu u každýho řádku riskovat ruletu, že se teda vážně stoprocentně nic neposralo, nikdo to nezapomněl zalogovat a modlit se, že to pro každej jeden potenciálně divnej vstup neskončí v kvadraticky se rozvírající množině všech stavů, který třeba někdo ani nečekal? Až udělám typo v nějakým link skriptu nebo se změní syntax a náhodou se stane chyba, mám mít jistotu, že se spouštění zastaví nebo se klepat, že se místo neplatnýho řádku spustí nějakej default na mazání disku? No ses zbláznil, ne? Zalogovat, zaříznout, hotovo. Zbytek jsou kecy.
+1 Člověk, který není schopen uznat chybu, si nezaslouží respekt.
Jen doufám, že v areálu Temelína používají poněkud odlišnou přístupovou logiku:
Terorista: Dobrý den, chci vyhodit Temelín do povětří! Ostraha: Nemáte platný občanský průkaz. Vítejte.
/etc/sysctl.conf
. Ono si to dovolí ji ignorovat a jen to vypíše varování! Kam jsme se to dostali?! Co kdyby to smazalo disk?!
Takhle to dopadá, když se někdo nenaučil při konverzi stringu na číslo ošetřit chyby…
Ale teď vážně: i kdybychom přijali tezi, že Poettering/systemd má právo určovat, která jména uživatelů jsou validní a která ne, pak má ten program při použití nevalidního jména zahlásit chybu a službu nespustit, ne si nějakým pseudonáhodným způsobem vybrat existujícího uživatele a spustit to pod ním. V případě, že se jedná o roota, jde navíc o jasnou bezpečnostní chybu, CVE id se přiděluje daleko větším prkotinám.
0ndra
, že? :)
nebo v jednotce vůbec login neuvádět.To je moc okatý
Usr=nobody
nebo User=@nobody
, systemd nepozná, o co se správce snažil, volbu ignoruje a napíše varování do logu.
User
a pokud nemá validné hodnotu, použije se root. A vedle toho existují uživatelské jednotky, které se spouští výhradně pod účtem uživatele, který je vlastní?
pak má ten program při použití nevalidního jména zahlásit chybu a službu nespustit,Take bych se k tomu klonil. Nicmene systemd neplatne nastaveni zaloguje a dale ignoruje, tedy i User=0day.
V případě, že se jedná o roota, jde navíc o jasnou bezpečnostní chybu, CVE id se přiděluje daleko větším prkotinám.Nemyslim si. Plno aplikaci muze root snadno nepozornosti nakonfigurovat tak, ze predstavuji bezpecnostni riziko, a CVE se kvuli tomu nedava.
V případě, že se jedná o roota, jde navíc o jasnou bezpečnostní chybu, CVE id se přiděluje daleko větším prkotinám.Co? Seš magor? Nějak to funguje, tak k čemu jako CVE?
i kdybychom přijali tezi, že Poettering/systemd má právo určovat, která jména uživatelů jsou validní a která neChapete nekdo tento argument?
In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
Mně hlavně přijde neuvěřitelná drzost, když se někdo jako Poettering s jeho přístupem k POSIXu a standardům obecně najednou zaštiťuje přenositelností, protože se mu to zrovna hodí.
Že je ten argument navíc ještě postavený na hlavu, to už je jen taková třešnička na dortu. Právě kvůli přenositelnosti by měla syntaxe systemd unit files mít pravidla co nejliberálnější, aby umožnila použití jakéhokoli jména uživatele, které se může na některém systému vyskytnout. Jenže oni asi myslí především na své univerzálně použitelné "one size fits all" unit files, ne na neposlušného uživatele, který by si chtěl svůj systém konfigurovat po svém.
getpwnam()
, je platné uživatelské jméno, a nepřidával další umělá omezení.
Tedy já nevím, školy nemám, jsem jen prostý člověkza nas se rikalo z delnicke rodiny
DESCRIPTION
The atoi() function converts the initial portion of the string pointed to by nptr to int. The behavior is the same as
strtol(nptr, NULL, 10);
except that atoi() does not detect errors.
uid_t uid = 0; if (syntax_valid_user(user)) uid = getpwnam(user)->pw_uid; else log("syntax error: %s", user); do_something(uid);BTW. V tomto kode je aj NULL-pointer dereference ako bonus :)
začal mě najednou zahrnovat do svého kruhu a choval se ke mě chvíli i srdečně. :)Našťastie si odolal :)
To je trošku v rozporu s tím, jak kdekdo tvrdí, že nemáme kritizovat osoby, ale kód.Ani ne. Casto se vybira z reseni, ktera nejsou cernobila, casto i blizka a ve finale se musi neco vybrat. Zatim mi prijde, ze pokud FOSS projekt nema v cele dostatecne silne a technicky zdatne osobnosti, zacne se casto utapet ve sporech, bez schopnosti nejake akce.
ale ve finále se máme přizpůsobovat jejich názoru.Prizpusobovat se nemusis, ale stejne tak nemas narok urcovat LP jak ma veci delat.
Pro pořádek: Na pubertu už taky nemám nárok, že?
# apt install sysvinit-core
vlastní distribuce, ale to asi není zrovna praktické řešení.ja myslim ze jo, napr. slackware s centos repository
Sigh, since this now attracting the trolls, I'm locking the conversation.Stejně nejlepší hláška. Škoda že to nefunguje tady…
Tudíž jen zbývá doufat, že mu to seberou a vezme si to pod křídla někdo, jehož ego nepůjde proti zájmu věci.Vzpomíná si ještě někdo na jméno Ulrich Drepper? I když kdyby to v případě lennárta netrvalo tak dlouho, nikdo by se asi nezlobil.
I když kdyby to v případě lennárta netrvalo tak dlouho, nikdo by se asi nezlobil.Nedelal bych si prehnana ocekavani - museli byste asi vymenit cely core team - Lennart Poettering, Kay Sievers, Harald Hoyer, Tom Gundersen, David Herrmann a dalsi - a to se jen tak nestane. Nicmene je to FOSS, fork muzete udelat kdykoliv a ukazat jim jak se to ma delat.
Nedelal bych si prehnana ocekavaniCož to já taky ne - dokud nebude každému jasné, že systemd a zejména jeho současné vedení je průser, nic se nestane.
Nicmene je to FOSS, fork muzete udelat kdykoliv a ukazat jim jak se to ma delat.Děkuji, svojí práce mám dost, takže s klidem zůstávám u těch "nespolehlivých" bash skriptů.