ubuntuusers.de

Hallo,

ein Artikel zu einem weiterem Programm aus der systemd Kiste: systemd-run. Wird voraussichtlich mit dem kommenden Ubuntu Release interessanter, wenn da systemd 256 (oder neuer) an Bord ist und damit der auf systemd-run aufsetzend sudo-Ersatz / Nachfolger? run0.

Gruß, noisefloor

Danke für den Artikel! Eine Ungereimtheit ist mir noch aufgefallen. Du schreibst

Standardmäßig wird für mit systemd-run gestartet Service Units der Wert oneshot genutzt.

In der Freedesktop-Dokumentation steht allerdings:

By default, services created with systemd-run default to the simple type

Außerdem würde ich in dieser Zeile zum besseren Verständnis auf systemd.service verlinken.

Done.

Gruß, noisefloor

Ich habe den ersten Absatz etwas umformuliert.

Außerdem sind mit noch folgenden Punkte aufgefallen:

Soll der Befehl mit Nutzerrechte ausgeführt werden, muss man die Option --user oder --uid NUTZER-ID mit angeben.

Es ist ungünstig, diese beiden Optionen in einem gemeinsamen Satz zu erklären, denn sie machen etwas völlig unterschiedliches:

• --user richtet den Befehl nicht an die für das System zuständige Instanz von systemd sondern an dessen Instanz für den aufrufenden Benutzer, der natürlich mit den Rechten des aufrufenden Benutzers läuft.

• --uid ohne --user richtet den Befehl an die für das System zuständige Instanz von systemd, welche als root läuft und daher auch vom aufrufenden Benutzer Root-Rechte erwartet, führt dann aber den auszuführenden Befehl als der per --uid benannte Benutzer und natürlich mit dessen Rechten aus.

• Ob beide Optionen zusammen angegeben werden können und was dann passiert, weiß ich noch nicht.

Auch in der Tabelle sind m.E. die beiden Optionen unvollständig/unrichtig erklärt.

Im letzten Beispiel wird eine Root-Shell aufgerufen, die nicht von der aufrufenden Shell erbt

• Das ist natürlich das wichtigste Beispiel.

• Das Konstrukt sudo systemd-run empfinde ich als pervers, insbesondere wenn man systemd-run als Alternative zu sudo versteht. Richtig wäre m.E. auf sudo zu verzichten, da das Programm ja selbst per Polkit die Root-Rechte abprüft.

• Leider stimmt die Erwartung „die nicht von der aufrufenden Shell erbt“ nicht, denn die Root-Shell hat dasselbe Arbeitsverzeichnis wie die aufrufende Shell! Und damit wird eine der von sudo GUI missachteten Vorsichtsmaßnahmen leider auch von systemd-run nicht beachtet.

Es ist ungünstig, diese beiden Optionen in einem gemeinsamen Satz zu erklären, denn sie machen etwas völlig unterschiedliches:

Ja, aber auf den Hintergrund wird an der Stelle nicht eingegangen. Formell ist der Satz richtig. Es gab vorher aber einen Fehler im Artikel diesbzgl., der jetzt korrigiert ist.

--uid ohne --user richtet den Befehl an die für das System zuständige Instanz von systemd, welche als root läuft und daher auch vom aufrufenden Benutzer Root-Rechte erwartet, führt dann aber den auszuführenden Befehl als der per --uid benannte Benutzer und natürlich mit dessen Rechten aus.

Das sehe ich anders, siehe https://manpages.ubuntu.com/manpages/jammy/man5/systemd.exec.5.html 🇬🇧

Leider stimmt die Erwartung „die nicht von der aufrufenden Shell erbt“ nicht, denn die Root-Shell hat dasselbe Arbeitsverzeichnis wie die aufrufende Shell!

-S impliziert die Option -d. Kann man sich jetzt drüber streiten, ob das unter "Vererbung" fällt oder nicht.

Und damit wird eine der von sudo GUI missachteten Vorsichtsmaßnahmen leider auch von systemd-run nicht beachtet.

Na dann go for it: Link zum Bugtracker 🇬🇧 von systemd.

Gruß, noisefloor

noisefloor schrieb:

Es ist ungünstig, diese beiden Optionen in einem gemeinsamen Satz zu erklären, denn sie machen etwas völlig unterschiedliches:

Ja, aber auf den Hintergrund wird an der Stelle nicht eingegangen. Formell ist der Satz richtig. Es gab vorher aber einen Fehler im Artikel diesbzgl., der jetzt korrigiert ist.

--uid ohne --user richtet den Befehl an die für das System zuständige Instanz von systemd, welche als root läuft und daher auch vom aufrufenden Benutzer Root-Rechte erwartet, führt dann aber den auszuführenden Befehl als der per --uid benannte Benutzer und natürlich mit dessen Rechten aus.

Das sehe ich anders, siehe https://manpages.ubuntu.com/manpages/jammy/man5/systemd.exec.5.html 🇬🇧

Was meinst Du? Diese Manpage erklärt überhaupt keine Aufrufoption eines Programms aus der Familie von systemd, und insbesondere auch nicht die Optionen --user und --system (Vorgabe, wenn --user nicht angegeben wird), sondern nur spezielle Direktiven für Units.

Die Optionen --user und --system werden z.B. in der Manpage für systemctl erklärt.

Leider stimmt die Erwartung „die nicht von der aufrufenden Shell erbt“ nicht, denn die Root-Shell hat dasselbe Arbeitsverzeichnis wie die aufrufende Shell!

-S impliziert die Option -d. Kann man sich jetzt drüber streiten, ob das unter "Vererbung" fällt oder nicht.

Ob es durch Vererbung zustande kommt oder nicht, lohnt keinen Streit. Mir kommt es nur auf das Ergebnis an: Das Arbeitsverzeichnis wird nicht verändert. Wenn es vorher /home/$USER war, wird das auch für die gestartete Root-Shell so sein. Das ist für den praktischen Gebrauch einer Root-Shell wichtig zu beachten. Es wird zwar im Prompt angezeigt, aber wer liest den schon?

Und damit wird eine der von sudo GUI missachteten Vorsichtsmaßnahmen leider auch von systemd-run nicht beachtet.

Na dann go for it: Link zum Bugtracker 🇬🇧 von systemd.

Ich sehe es durchaus nicht als BUG von systemd-run an, sondern die Erwartungshaltung des Benutzers wird nicht erfüllt: Die Isolation ist nicht vollständig und sie kann es auch gar nicht sein, solange man in der Root-Shell auf das System einwirken können will.

Jedenfalls ist eine Root-Shell per systemd-run zwar ein wenig anders gefährlich als eine Root-Shell per sudo, aber keinesfalls ungefährlich. Was nicht an systemd-run liegt, sondern weil eine Root-Shell nun mal eine Shell für den Benutzer root ist.

Da ich ab sofort und bis auf weitere weder größere Überarbeitungen von Artikel machen noch neue Artikel für das Wiki von ubuntuusers.de erstellen werde, kann gerne jemand anders diese Baustelle zu Ende bringen oder sie kann auf verlassen gesetzt oder, wenn sich niemand findet, kann sie auch gelöscht werden.