systemd

[raa]

Hallo,

https://de.wikipedia.org/wiki/Systemd#Kritik

Insbesondere das ist besorgniserregend:

Im September 2016 wurde ein Bug bekannt, der jedem unpriviligierten Benutzer eine Denial of Service-Attacke auf systemd und die damit verbundenen Prozesse ermöglicht.

Wer weiß da Genaueres? Also wenn da z.B. steht:

Linus Torvalds gab an, er habe keine feste Meinung zu systemd; einige Eigenschaften wie binäre Logs seien irrsinnig, aber das seien Detailfragen und kein grundsätzliches Problem. Die systemd-Entwickler hätten generell eine zu großzügige Haltung gegenüber Programmfehlern und Kompatibilitätsproblemen. InfoWorld berichtete, systemd-Entwickler hätten Programmierfehler ignoriert und Bugreports geschlossen, ohne die Fehler zu beheben, was dazu geführt habe, dass Torvalds mit Kay Sievers einen der führenden systemd-Entwickler vom Kernel-Development ausgeschlossen habe ...

Naja, mein Jessie arbeitet auch mit systemd, und bislang zu meiner vollen Zufriedenheit (wenn irgendwas nicht oder instabil lief, habe ich schlussendlich den Fehler immer bei mir selber gefunden), das kann sich aber schlagartig ändern, wie's aussieht.

Also: Welche Erfahrungswerte gibt's diesbezüglich, und wo kann man das nachlesen?

[rendegast]

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

macht hier nichts, nicht mal im 'journalctl',
systemd 230 jessie-backports (eine mittlerweile wohl doch ziemlich stabile Version,
angefangen hat es mit Version 44(?) http://snapshot.debian.org/package/systemd/).
Wohl ein dummer, dummer, geschlossener Bug,
warum es sowas nach wikipedia schafft?

Linus Torvalds gab an, ...
... einen der führenden systemd-Entwickler vom Kernel-Development ausgeschlossen habe ...

kernel.org-Gerangel.
google "kai sievers kernel.org" -> 04.04.2014 !!!
Der Sievers dürfte seinen Zugang wohl wiederhaben oder nie verloren (Anfang April).
IMO ein Blog-Thema, nix wikipedia.




---------------------------------------------------------
opensuse-LEAP (als systemd-System), letztes Upgrade ~ 1 Woche.
Anschließend 'zypper ps', um neu zu startende Prozesse zu zeigen
--> 'systemctl restart' resp. 'systemctl daemon-reexec'
Anschließendes 'zypper ps' zeigt weiterhin Prozesse.
Neustart -> 'zypper ps' zeigt weiterhin Prozesse.
???
Bug in systemd/systemctl? Bug in zypper?

[raa]

Hm, meine Pakteverwaltung sagt mir: "Installierte Version 215-17+deb8u4, neueste Version 230-7~bpo8+2" - da wäre wohl eine Aktualisierung angebracht, danach wirklich nichts mehr zu befürchten?

[DeletedUserReAsG]

[…] danach wirklich nichts mehr zu befürchten?

Jede Software hat Fehler. Nichts zu befürchten wird man also nie haben.

[rendegast]

Sichere Dein wordpress so ab, daß Benutzer keine shell-Befehle o.ä. der oberen Art mehr absetzen können.

[raa]

[…] danach wirklich nichts mehr zu befürchten?

Jede Software hat Fehler. Nichts zu befürchten wird man also nie haben.

Klar doch. Aber nicht so ein Horroszenario.

Sichere Dein wordpress so ab, daß Benutzer keine shell-Befehle o.ä. der oberen Art mehr absetzen können.

Das konnten sie noch nie. wordpress kenne ich nämlich gar nicht. Wie überhaupt jeder Versuch, irgendwas Ausführbares gegen meinen Willen auf meine Kiste hier zu bringen, ziemlich aussichtslos sein dürfte.

Hab' also mal die Aktualiserung laufen lassen, das Changelog könnte von Interesse sein:

Code: Alles auswählen

ifupdown (0.8.1) unstable; urgency=medium

  The /etc/default/networking file is now read even when systemd is used,
  although its use is not recommended.

 -- Guus Sliepen <guus@debian.org>  Wed, 02 Dec 2015 23:25:41 +0100

ifupdown (0.8) unstable; urgency=medium

  Ifupdown now comes with a systemd service file. Any options specified in
  /etc/default/networking will no longer be used. If you are using
  CONFIGURE_INTERFACES=no, then run "systemctl disable networking" instead.
  If you are using EXCLUDE_INTERFACES, then edit /etc/network/interfaces and
  remove those interfaces from any "auto" keywords.

  Ifupdown will now be more strict when errors occur, and will also properly
  return a non-zero exit code when (de)configuring an interface fails. Please
  ensure your /etc/network/interfaces is correct and that your interfaces can
  be brought up and down without errors, especially during system startup.

  Ifupdown now has more fine-grained locking, allowing concurrent calls of
  ifup and ifdown. It is also allowed to call ifup and ifdown from a (pre-)up
  or (post-)down line from /etc/network/interfaces, as long as no recursion
  occurs.

  You can now use the "inherits" keyword to copy settings from another
  interface stanza.

  RFC 4361 DDNS support is now enabled by default for inet dhcp interfaces if
  isc-dhcp-client is installed.

 -- Guus Sliepen <guus@debian.org>  Sun, 22 Nov 2015 21:19:44 +0100

systemd (224-2) unstable; urgency=medium

  * This version splits out systemd-nspawn, systemd-machined, and machinectl
    into the new "systemd-container" package. That now also enables
    systemd-importd.

 -- Martin Pitt <mpitt@debian.org>  Sat, 22 Aug 2015 15:58:43 +0200

[raa]

Hab' also mal die Aktualiserung laufen lassen, das Changelog könnte von Interesse sein ...

Und dass die auch ein Kernel-Update auf 4.7.0-0.bpo.1-amd64 verlangt, aber das war wohl klar.

[rendegast]

das Changelog könnte von Interesse sein:

ifupdown (0.8.1) unstable; urgency=medium
...
-- Guus Sliepen <guus@debian.org> Wed, 02 Dec 2015

systemd (224-2) unstable; urgency=medium
...
-- Martin Pitt <mpitt@debian.org> Sat, 22 Aug 2015

?
denn

Code: Alles auswählen

# aptitude versions ^ifupdown$ ^systemd$ --disable-columns
Package ifupdown:                          
p A 0.7.53.1 stable 500
i A 0.8.13~bpo8+1 jessie-backports 111
p A 0.8.16 testing,unstable 101

Package systemd:
p A 215-17+deb8u5 stable 500
i A 230-7~bpo8+2 jessie-backports 111
p A 232-7 testing,unstable 101

systemd (224-2) unstable; urgency=medium

* This version splits out systemd-nspawn, systemd-machined, and machinectl
into the new "systemd-container" package. That now also enables
systemd-importd.

-- Martin Pitt <mpitt@debian.org> Sat, 22 Aug 2015

Da wurden einige Tools (Container/Docker-Kram) in ein eigenes Paket ausgelagert,
was ist daran diesbezüglich interessant?

[raa]

denn

Code: Alles auswählen

aptitude versions ^ifupdown$ ^systemd$ --disable-columns

Hm, das bringt bei mir:

Code: Alles auswählen

Paket ifupdown:                              
p  0.7.53.1 stable 500
i  0.8.13~bpo8+1 jessie-backports 100

Paket ifupdown:i386:
p  0.7.53.1 stable 500
p  0.8.13~bpo8+1 jessie-backports 100

Paket systemd:
p  215-17+deb8u5 stable 500
i  230-7~bpo8+2 jessie-backports 100

Paket systemd:i386:
p  215-17+deb8u5 stable 500
p  230-7~bpo8+2 jessie-backports 100

ifupdown bringt auch beim Booten (mit dem neuen wie mit dem alten Kernel) noch eine Fehlermeldung ("Failed irgendwas" - find' ich nur in keiner Logdatei wieder). Das Netzwerk läuft zwar (sonst könnte ich ja gar nicht hier posten), aber irgendwas stimmt da also noch nicht ganz, aber was?

[raa]

systemd 230 jessie-backports (eine mittlerweile wohl doch ziemlich stabile Version,

Najaa, soo stabil also wohl noch nicht ...

[raa]

Hab' also reumütig den letzten als einwandfrei funktionierend bekannten Stand meines Systems zurückgespielt, das war's. Punkt.