run0

[Ralph Aichinger]

Was ist die allgemeine Meinung hier zu run0, dem sudo-Ersatz von
systemd?

https://mastodon.social/@pid_eins/112353324518585654

Einerseits kommen mir die technischen Argumente stimmig vor,
andererseits finde ich schon sudo mühevoll zu tippen, und run0 noch mal
eine Spur blöder. Das wär für mich ein Beispiel für ein Kommando das
kurz sein sollte, und ich finde die Benennung (genauso wie bei
systemctl) ärgerlich. Das tippt man alles zu oft, als dass es so
kryptisch heißen sollte, IMHO. rz oder notfalls r0 wär mir lieber
gewesen.

/ralph

[Martin Schnitkemper]

Post by Ralph Aichinger
kryptisch heißen sollte, IMHO. rz oder notfalls r0 wär mir lieber
gewesen.

…dann setze doch einen entsprechenden Alias oder symbolischen Link darauf.

[Ralph Aichinger]

???dann setze doch einen entsprechenden Alias oder symbolischen Link darauf.

Das kann man bei seinem eigenen System daheim machen, wenn man das aber
beruflich nutzt, oder gar bei Kundensystemen, dann kann man solche
Sachen typischwerweise nicht tun. Da kann man auch im GUI keine "netten
Utilities" installieren etc.

Und wenn das da bei 50% der Rechner als Alias setzbar ist, und bei 50%
nicht, dann stolpert man noch mal mehr drüber, und nervt es noch mehr.
Dann schon lieber an den "richtigen" Namen gewöhnen.

/ralph

[Marco Moock]

Post by Ralph Aichinger
Und wenn das da bei 50% der Rechner als Alias setzbar ist, und bei 50%
nicht, dann stolpert man noch mal mehr drüber, und nervt es noch mehr.
Dann schon lieber an den "richtigen" Namen gewöhnen.

Ist bei ll schon nervig - und manche Systeme haben das als Default in
den Aliasen.

[Ralph Aichinger]

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als Default in
den Aliasen.

Ja, ich hab mal in einer Firma gearbeitet, wo das standardmäßig so
gemacht wurde. Nur auf Kundenrechnern war das dann doch oft nicht der
Fall.

/ralph

[Martin Schnitkemper]

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als Default in
den Aliasen.

…und warum ist es dann nervig?

Wenn er als default gesetzt wird, dann trifft es nicht mehr zu, dass er
nur auf 50% der Rechner gesetzt ist, und bei 50% nicht, sondern er ist dann
bei allen Rechnern gesetzt.

[Marco Moock]

Post by Martin Schnitkemper

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als Default
in den Aliasen.

…und warum ist es dann nervig?
Wenn er als default gesetzt wird, dann trifft es nicht mehr zu, dass
er nur auf 50% der Rechner gesetzt ist, und bei 50% nicht, sondern er
ist dann bei allen Rechnern gesetzt.

Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht. Bei anderen weiß
ich es nicht.
Jedenfalls ist auch das schon nervig genug.

[Martin Schnitkemper]

Post by Marco Moock
Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht. Bei anderen weiß
ich es nicht.
Jedenfalls ist auch das schon nervig genug.

Das erklärt aber immer noch nicht, was daran nervig sein soll, wenn
systemweit ein Alias gesetzt wird, der allen Benutzern zur Verfügung steht.

[Ralph Aichinger]

Post by Martin Schnitkemper
Das erklärt aber immer noch nicht, was daran nervig sein soll, wenn
systemweit ein Alias gesetzt wird, der allen Benutzern zur Verfügung steht.

Das ist der nicht-nervige (aber eventuell aus anderen Gründen
problematische) Teil.

Der nervige Teil ist, dass man, wenn man an das Alias gewöhnt ist, dann
überall z.B. "ll" tippt.

***@surface:~$ ll
bash: ll: command not found

/ralph

[Stefan+ (Stefan Froehlich)]

Post by Ralph Aichinger

Post by Martin Schnitkemper
Das erklärt aber immer noch nicht, was daran nervig sein soll, wenn
systemweit ein Alias gesetzt wird, der allen Benutzern zur Verfügung steht.

Das ist der nicht-nervige (aber eventuell aus anderen Gründen
problematische) Teil.
Der nervige Teil ist, dass man, wenn man an das Alias gewöhnt ist,
dann überall z.B. "ll" tippt.

...weshalb ich mir das nie angewöhnt habe. Der Zeitnachteil von
ls -l verliert sich beim Ansehen des Listings vollständig.

Insofern ist so ein Alias dann auch nicht mehr nervig, denn er fällt
mir gar nicht erst auf.

Servus,
Stefan

[Gerald E¡scher]

Post by Marco Moock

Post by Martin Schnitkemper

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als Default
in den Aliasen.

…und warum ist es dann nervig?
Wenn er als default gesetzt wird, dann trifft es nicht mehr zu, dass
er nur auf 50% der Rechner gesetzt ist, und bei 50% nicht, sondern er
ist dann bei allen Rechnern gesetzt.

Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht.

Bei Debian kannst du wahlweise in der ~/.bashrc die entsprechenden
Kommentare entfernen oder eine ~/.bash_aliases anlegen.

[Marco Moock]

Post by Gerald E¡scher

Post by Marco Moock

Post by Martin Schnitkemper

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als
Default in den Aliasen.

…und warum ist es dann nervig?
Wenn er als default gesetzt wird, dann trifft es nicht mehr zu,
dass er nur auf 50% der Rechner gesetzt ist, und bei 50% nicht,
sondern er ist dann bei allen Rechnern gesetzt.

Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht.

Bei Debian kannst du wahlweise in der ~/.bashrc die entsprechenden
Kommentare entfernen oder eine ~/.bash_aliases anlegen.

Genau da sind wir wieder an dem Punkt, an dem es nervt, wenn man das
auf allen Systemen so machen muss, mit denen man zu tun hat.
Verlassen kann man sich auf die Existenz hier nicht.

[Tim Landscheidt]

Post by Marco Moock

Post by Gerald E¡scher

Post by Marco Moock

Post by Martin Schnitkemper

Post by Marco Moock
Ist bei ll schon nervig - und manche Systeme haben das als
Default in den Aliasen.

…und warum ist es dann nervig?
Wenn er als default gesetzt wird, dann trifft es nicht mehr zu,
dass er nur auf 50% der Rechner gesetzt ist, und bei 50% nicht,
sondern er ist dann bei allen Rechnern gesetzt.

Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht.

Bei Debian kannst du wahlweise in der ~/.bashrc die entsprechenden
Kommentare entfernen oder eine ~/.bash_aliases anlegen.

Genau da sind wir wieder an dem Punkt, an dem es nervt, wenn man das
auf allen Systemen so machen muss, mit denen man zu tun hat.
Verlassen kann man sich auf die Existenz hier nicht.

Der geneigte Benutzer verfällt dann nicht in Defätismus,
sondern greift zu Konstrukten wie:

| ssh -t "$user@$host" bash -lc '"function r0 { run0 \"\$@\"; }; export -f r0; exec bash"'

oder gleich einem expect(1)-Script.

Tim

[Ralph Aichinger]

Hm, solche Konstrukte wären echt zu überlegen.

/ralph

[Gerald E¡scher]

Post by Tim Landscheidt

Post by Marco Moock

Post by Gerald E¡scher
Bei Debian kannst du wahlweise in der ~/.bashrc die entsprechenden
Kommentare entfernen oder eine ~/.bash_aliases anlegen.

Genau da sind wir wieder an dem Punkt, an dem es nervt, wenn man das
auf allen Systemen so machen muss, mit denen man zu tun hat.
Verlassen kann man sich auf die Existenz hier nicht.

Der geneigte Benutzer verfällt dann nicht in Defätismus,

Bis ich das einmal brauchen werde, habe ich das Konstrukt längst
vergessen ;-(

Post by Tim Landscheidt
oder gleich einem expect(1)-Script.

Ich werde r0 einfach in ~/.bash_aliases aufnehmen, aber eigentlich
empfinde ich das Tippen von "run0" nicht umständlicher als "sudo".

[Sieghard Schicktanz]

Hallo Gerald,

Post by Gerald E¡scher
Ich werde r0 einfach in ~/.bash_aliases aufnehmen, aber eigentlich
empfinde ich das Tippen von "run0" nicht umständlicher als "sudo".

BTW, _was_ genau macht dieses "run0" denn eigentlich?
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das ein
vollständiger Ersatz dafür?
(Wobei im letzteren Fall die Bezeichnung denkbar schlecht gewählt wäre,
weil sie halt ersteres implizieren könnte.)

[Ralph Aichinger]

Post by Sieghard Schicktanz
BTW, _was_ genau macht dieses "run0" denn eigentlich?
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das ein
vollständiger Ersatz dafür?

Ich denke es ist ein modernerer Ersatz dafür, so wie man sudo als
moderneren Ersatz von su sehen kann.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Sieghard Schicktanz
BTW, _was_ genau macht dieses "run0" denn eigentlich?
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das ein
vollständiger Ersatz dafür?

Ich denke es ist ein modernerer Ersatz dafür, so wie man sudo als
moderneren Ersatz von su sehen kann.

Wer diesen Vergleich spielt, kommt aber bitte an runas aus der
BSD-Welt nicht vorbei.

Grüße
Marc

[Peter J. Holzer]

Post by Sieghard Schicktanz

Post by Gerald E¡scher
Ich werde r0 einfach in ~/.bash_aliases aufnehmen, aber eigentlich
empfinde ich das Tippen von "run0" nicht umständlicher als "sudo".

BTW, _was_ genau macht dieses "run0" denn eigentlich?

Es weist systemd an, ein Kommando als der Target-User zu starten.
Das Kommando ist dann also kein Kind-Prozess von run0, erbt daher nicht
dessen Environment (was bei sudo des öfteren problematisch war), run0
selbst ist auch nicht suid. Die Kommunikation erfolgt über ein pty.

Das ist also eher so, als ob man ein »ssh ***@localhost kommando«
machen würde als ein »sudo -u user kommando«.

Post by Sieghard Schicktanz
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das ein
vollständiger Ersatz dafür?

Es soll ein vollständiger Ersatz sein. Die Grundidee ist, setuid
vollständig loszuwerden (oder zumindest überflüssig zu machen).

hp

[Thomas Zajic]

Post by Peter J. Holzer
[...]

Post by Sieghard Schicktanz
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das ein
vollständiger Ersatz dafür?

Es soll ein vollständiger Ersatz sein. Die Grundidee ist, setuid
vollständig loszuwerden (oder zumindest überflüssig zu machen).

Ich glaube, irgendwo gelesen zu haben, daß es zu diesem Zweck polkit
(und damit im Endeffekt pkexec) als Backend verwendet. Und pkexec ist
ebenfalls setuid. Damit wird die setuid Problematik eigentlich nur von
einem Binary (sudo) auf ein anderes (pkexec) verschoben. Oder sehe ich
das falsch? Ist pkexec "besser" oder sicherer als sudo?

Und grundsätzlich: irgendetwas als ein anderer User laufen lassen ist
doch ohnehin nur für root erlaubt (oder benötigt zumindest root Rechte),
und somit *muss* doch irgendetwas in der Exekutionskette letztendlich
setuid root sein, wenn man nicht ohnehin schon root ist. Oder sehe ich
das ebenfalls falsch? Gibt es da einen "besseren" oder sichereren
Mechanismus dafür?

LG
Thomas

[Marc Haber]

Post by Thomas Zajic
Und grundsätzlich: irgendetwas als ein anderer User laufen lassen ist
doch ohnehin nur für root erlaubt (oder benötigt zumindest root Rechte),
und somit *muss* doch irgendetwas in der Exekutionskette letztendlich
setuid root sein, wenn man nicht ohnehin schon root ist. Oder sehe ich
das ebenfalls falsch? Gibt es da einen "besseren" oder sichereren
Mechanismus dafür?

pid 1 ist root.

Grüße
Marc

[Sieghard Schicktanz]

Hallo Marc,

Post by Marc Haber

Post by Thomas Zajic
Und grundsätzlich: irgendetwas als ein anderer User laufen lassen ist
doch ohnehin nur für root erlaubt (oder benötigt zumindest root Rechte),
und somit *muss* doch irgendetwas in der Exekutionskette letztendlich
setuid root sein, wenn man nicht ohnehin schon root ist. Oder sehe ich
das ebenfalls falsch? Gibt es da einen "besseren" oder sichereren
Mechanismus dafür?

pid 1 ist root.

Und bei welchem Druck liegt die Platzgrenze? (Weil, wird also weiter
aufgeblasen.)

[Sieghard Schicktanz]

Hallo Peter,

Post by Peter J. Holzer

Post by Sieghard Schicktanz
BTW, _was_ genau macht dieses "run0" denn eigentlich?

Es weist systemd an, ein Kommando als der Target-User zu starten.

D.h. der Name ist falsch. Naschön, Namen sind Schall und Rauch...

Post by Peter J. Holzer
Das Kommando ist dann also kein Kind-Prozess von run0, erbt daher nicht
dessen Environment (was bei sudo des öfteren problematisch war), run0

Naja,auch wenn sudo da ein paar Einflußmöglichkeiten bietet, mag das in
manchen Fällen nicht das ermöglicht haben, was gewünscht war.

Post by Peter J. Holzer
selbst ist auch nicht suid. Die Kommunikation erfolgt über ein pty.

Und wer führt den Befehl dann aus?

Post by Peter J. Holzer
machen würde als ein »sudo -u user kommando«.

Das entspräche dann doch in etwa einem "sudo -i" oder so ähnlich?

Post by Peter J. Holzer

Post by Sieghard Schicktanz
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das
ein vollständiger Ersatz dafür?

Es soll ein vollständiger Ersatz sein. Die Grundidee ist, setuid
vollständig loszuwerden (oder zumindest überflüssig zu machen).

Da muß es dann aber "irgendeine zentrale Instanz" geben - die natürlich mit
root-Rechten läuft - die auf einen solchen Befehl einen "Prozess" unter dem
gewünschten Benutzer startet sowie ggfs. den überwacht und das Ergebnis
zurückmeldet. Wo liegt da der große (Sicherheits-) Vorteil?

[Peter J. Holzer]

Post by Sieghard Schicktanz

Post by Peter J. Holzer

Post by Sieghard Schicktanz
BTW, _was_ genau macht dieses "run0" denn eigentlich?

Es weist systemd an, ein Kommando als der Target-User zu starten.

D.h. der Name ist falsch. Naschön, Namen sind Schall und Rauch...

Post by Peter J. Holzer
Das Kommando ist dann also kein Kind-Prozess von run0, erbt daher nicht
dessen Environment (was bei sudo des öfteren problematisch war), run0

Naja,auch wenn sudo da ein paar Einflußmöglichkeiten bietet, mag das in
manchen Fällen nicht das ermöglicht haben, was gewünscht war.

Post by Peter J. Holzer
selbst ist auch nicht suid. Die Kommunikation erfolgt über ein pty.

Und wer führt den Befehl dann aus?

Systemd (oder einer seiner Hilfsprozesse).

Post by Sieghard Schicktanz

Post by Peter J. Holzer
machen würde als ein »sudo -u user kommando«.

Das entspräche dann doch in etwa einem "sudo -i" oder so ähnlich?

Nein, bei sudo -i ist die Shell ein Kindprozess von sudo:

hjp pts/1 \_ zsh
root pts/1 | \_ sudo -i
root pts/2 | \_ sudo -i
root pts/2 | \_ -bash

(wobei da interessanterweise auch ein Pseudoterminal involviert ist -
ist mir noch nie aufgefallen)

Bei run0 hingegen ist das nicht der Fall, genausowenig wie bei ssh. Da
ist das ausgeführte Kommando (kann eine Shell sein, muss aber nicht) ein
Kind des sshd:

hjp pts/1 \_ zsh
hjp pts/1 | \_ ssh ***@localhost

root ? sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root ? \_ sshd: ***@pts/2
root pts/2 \_ -bash

run0 habe ich (noch) nicht, kann ich also nicht live demonstrieren.
Aber so wie ich es verstanden habe, ist das ausgeführte Kommando dann
entweder ein Kind von init selbst oder von einem dafür spezialisierten
Daemon.

Post by Sieghard Schicktanz

Post by Peter J. Holzer

Post by Sieghard Schicktanz
Ist das eine auf uid 0 eingeschränkte Variante von sudo, oder ist das
ein vollständiger Ersatz dafür?

Es soll ein vollständiger Ersatz sein. Die Grundidee ist, setuid
vollständig loszuwerden (oder zumindest überflüssig zu machen).

Da muß es dann aber "irgendeine zentrale Instanz" geben - die natürlich mit
root-Rechten läuft - die auf einen solchen Befehl einen "Prozess" unter dem
gewünschten Benutzer startet sowie ggfs. den überwacht und das Ergebnis
zurückmeldet.

Klar: Systemd. Das macht ja ohnehin genau das: Prozesse unter einem User
(und gegebenfalls in einem eigenen Namespace) starten und überwachen.

Post by Sieghard Schicktanz
Wo liegt da der große (Sicherheits-) Vorteil?

Bessere Isolation. Über Kindprozesse hat man recht viel Kontrolle. Über
Prozsse, die von einem Daemon gestartet werden, nicht.

Ob das in der Praxis einen Unterschied macht (insbesondere, wenn beide
Mechanismen zur Verfügung stehen), weiß ich nicht. Aber ich kann den
Gedankengang nachvollziehen.

hp

[Ralph Aichinger]

Post by Peter J. Holzer
hjp pts/1 \_ zsh
root pts/1 | \_ sudo -i
root pts/2 | \_ sudo -i
root pts/2 | \_ -bash
(wobei da interessanterweise auch ein Pseudoterminal involviert ist -
ist mir noch nie aufgefallen)
Bei run0 hingegen ist das nicht der Fall, genausowenig wie bei ssh. Da
ist das ausgeführte Kommando (kann eine Shell sein, muss aber nicht) ein
hjp pts/1 \_ zsh
root ? sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root pts/2 \_ -bash

Bei mir (Debian) schaut run0 so aus (login auf tty3, also einer
Textkonsole):

208576 tty3 Ss 0:00 /bin/login -p --
208629 tty3 S 0:00 \_ -bash
209733 tty3 S+ 0:00 \_ run0 bash
209734 tty3 Sl+ 0:00 \_ /usr/bin/pkttyagent --notify-fd 10 --fallback

und dann noch der eigentlich unter run0 privilegiert laufende Prozess:

209757 pts/6 Ss 0:00 /usr/bin/bash
209777 pts/6 S+ 0:00 \_ /usr/games/snake

Ja, ich weiß, man startet keine Spiele als root, das war damit ich die
richtige bash finde.

/ralph

[Martin Schnitkemper]

Post by Marco Moock
Genau da sind wir wieder an dem Punkt, an dem es nervt, wenn man das
auf allen Systemen so machen muss, mit denen man zu tun hat.

Du hast doch selber gesagt, dass es bei bestimmten Distributionen ein
Default-Alias ist, also steht er doch allen Benutzern zur Verfügung. Was
gibt es denn dann noch "auf allen Systemen" zu machen, was dich so nervt?

Post by Marco Moock
Verlassen kann man sich auf die Existenz hier nicht.

Verstehe ich nicht; vielleicht nicht distributionsübergreifend, aber warum
sollte der Alias auf einem System nicht existieren, wenn es eine Default-
Einstellung ist?

[Marco Moock]

Post by Martin Schnitkemper
Verstehe ich nicht; vielleicht nicht distributionsübergreifend, aber
warum sollte der Alias auf einem System nicht existieren, wenn es
eine Default- Einstellung ist?

Distributionsübergreifend ist hier das Stichwort.
Fällt mir im Alltag halt auf, ebenfalls wie Eigenschaften der inputrc,
die mir öfter auf die Füße fallen, wenn ich Strg+Del nutzen will.

[Martin Schnitkemper]

Post by Marco Moock
Distributionsübergreifend ist hier das Stichwort.
Fällt mir im Alltag halt auf, ebenfalls wie Eigenschaften der inputrc,
die mir öfter auf die Füße fallen, wenn ich Strg+Del nutzen will.

Einer der Stärken von Linux ist seine Vielfalt, die sich in den
verschiedenen Distributionen widerspiegelt. Deswegen ist es normal und
gewollt, das sich die Distribution in Details voneinander unterscheiden, und
da gibt es weitaus größere Unterschiede als ausgerechnet ein gesetzter
Alias.

Wenn man von einem Distributor erwartet, dass er nicht einmal einen Alias
setzen darf, nur weil es ihn in einer anderen Distribution nicht gibt,
könnte man sich die Vielfalt der Distributionen gleich schenken, und es
würde eine für alle(s) reichen.

Ich kann mir auch weder im privaten noch kommerziellen Umfeld ein Szenario
vorstellen, in dem man mit verschiedenen Distributionen hantieren muss.
Wenn das bei dir so ist, dann musst du dich eh mit den Besonderheiten einer
jeden eingesetzten Distribution auseinandersetzen, und da gibt es bestimmt
nervigere Dinge als ein fehlender Alias.

[Marc Haber]

Post by Martin Schnitkemper
Ich kann mir auch weder im privaten noch kommerziellen Umfeld ein Szenario
vorstellen, in dem man mit verschiedenen Distributionen hantieren muss.

Ich kann das schon. Da gibt es zum Beispiel die eine Firma, die
bevorzugt Debian einsetzt, aber auch das eine oder andere kommerzielle
Produkt hat, das nur für Red Hat oder Ubuntu zertifiziert und
supportet ist.

Oder die Firma, bei der ein Schlipsträger entschieden hat, dass Debian
wegen des "fehlenden Kommerziellen Supports" nicht mehr tragbar ist
und deswegen zu Red Hat migriert werden muss, dann aber nach dem
Eingang der ersten Rechnung von Red Hat ein "eiwei, das ist aber
teuer" Meeting einberufen wurde, das entschlossen hat, dass man
keinesfalls zugeben kann dass die Migration weg von Debian ein Fehler
war und man deswegen zu CentOS weiter migriert.

In beiden Fällen haben die wenigen Leute mit Ahnung natürlich ihr
Konfigurationsmanagement so eingestellt, dass die Distibutionen sich
möglichst ähnlich werden. Die einheitliche Verteilung von shellaliases
und interner Tools gehört zu sowas natürlich dazu.

Post by Martin Schnitkemper
Wenn das bei dir so ist, dann musst du dich eh mit den Besonderheiten einer
jeden eingesetzten Distribution auseinandersetzen, und da gibt es bestimmt
nervigere Dinge als ein fehlender Alias.

Freilich.

Das ist übrigens auch für mich einer der Gründe, warum ich die bash
benutze: Die ist wenigstens überall drauf.

Grüße
Marc

[Stefan Kaintoch]

Post by Marc Haber

Post by Martin Schnitkemper
Ich kann mir auch weder im privaten noch kommerziellen Umfeld ein Szenario
vorstellen, in dem man mit verschiedenen Distributionen hantieren muss.

Ich kann das schon. Da gibt es zum Beispiel die eine Firma, die
bevorzugt Debian einsetzt, aber auch das eine oder andere kommerzielle
Produkt hat, das nur für Red Hat oder Ubuntu zertifiziert und
supportet ist.

Und nicht nur Du.
Bei uns wird zB auf Ubuntu, Debian und-was-weiß-ich-noch entwickelt. Die
fertigen Produkte laufen aber auf einer angepassten Yocto-Variante.
Als Entwickler muß man sich ausreichend mit beidem auskennen.

Post by Marc Haber
Das ist übrigens auch für mich einer der Gründe, warum ich die bash
benutze: Die ist wenigstens überall drauf.

FACK

[Ralph Aichinger]

Post by Marc Haber
Oder die Firma, bei der ein Schlipsträger entschieden hat, dass Debian
wegen des "fehlenden Kommerziellen Supports" nicht mehr tragbar ist
und deswegen zu Red Hat migriert werden muss, dann aber nach dem
Eingang der ersten Rechnung von Red Hat ein "eiwei, das ist aber
teuer" Meeting einberufen wurde, das entschlossen hat, dass man
keinesfalls zugeben kann dass die Migration weg von Debian ein Fehler
war und man deswegen zu CentOS weiter migriert.

Ein weiteres Szenario ist: Firma X kauft Firma Y auf, und die haben mit
jeweils anderen Distributionen angefangen.

Oder Abteilung X verwendet Linux im Unternehmen, Abteilung Y fängt
später auch damit an, findet es aber nicht der Mühe wert mit Abteilung X
zu reden. Nach längerer Zeit kommt man drauf, dass man zwei
unterschiedliche Varianten verwendet.

Das kannst du auch mit Windows-Software durchspielen. Es gibt
Unternehmen, die haben 2 unterschiedliche Groupware-Systeme, oder 2
unterschiedliche Warenwirtschaftssysteme, etc.

/ralph

[Stefan+ (Stefan Froehlich)]

Post by Martin Schnitkemper
Ich kann mir auch weder im privaten noch kommerziellen Umfeld ein
Szenario vorstellen, in dem man mit verschiedenen Distributionen
hantieren muss.

Das macht nichts, ich habe auch keine Phantasie :)

Auf meinen Systemen herrscht z.B. eine Debian Monokultur, aber ab
und an kommt ein Kunde und hätte gerne ein System auf seiner eigenen
Infrastruktur aufgesetzt und betreut. Und dann stehe ich mit
irgendeinem kommerziellen Linux da (Debian verwendet irgendwie
keiner), und alles fühlt sich zwar vertraut und bekannt an, aber
halt doch anders.

Post by Martin Schnitkemper
da gibt es bestimmt nervigere Dinge als ein fehlender Alias.

Natürlich.

Servus,
Stefan

[Thomas Hochstein]

Post by Marco Moock
Ubuntu, Fedora und RHEL setzen das, Debian z.B. nicht.

Jein. Es ist auskommentiert.

[Martin Schnitkemper]

Post by Ralph Aichinger
Das kann man bei seinem eigenen System daheim machen, wenn man das aber
beruflich nutzt, oder gar bei Kundensystemen, dann kann man solche
Sachen typischwerweise nicht tun. Da kann man auch im GUI keine "netten

Was spricht denn gegen einen symbolischen Link?

Der wäre dann systemweit für alle berechtigten Benutzer verfügbar, und wenn
man ihn in ein Installationspaket packt dann ist er auch der
Paketverwaltung bekannt und kann auf allen betroffenen Systemen verteilt
werden.

Wenn du zugunsten von run0 ganz auf sudo verzichten kannst, könntest du
sudo auch de-installieren und einen symbolischen Link von run0 auf sudo
setzen, dann wäre es für die Benutzer transparent, weil sich für sie in der
Handhabung nichts ändert sondern nur die dahinter liegende Behandlung.

[Ralph Aichinger]

Post by Martin Schnitkemper
Der wäre dann systemweit für alle berechtigten Benutzer verfügbar, und wenn
man ihn in ein Installationspaket packt dann ist er auch der
Paketverwaltung bekannt und kann auf allen betroffenen Systemen verteilt
werden.

Typischerweise wird man wegen solchem Fluff keinen formalen Prozess
anstoßen (Tickets aufmachen etc, womöglich sogar zurechenbare Kosten
generieren etc.).

Wenn dann irgendeine obskure Software bricht, weil r0, rz oder sudo ein
Symlink auf irgendwas anderes ist, dann will man aber auch nicht schuld
sein, weil man das auf inoffiziellen Kanälen reingeschmuggelt hat.

Ich hab keine Hemmungen auf von mir betreuten Systemen Software zu
installieren, die ich zur Fehlersuche brauche (z.B. tcpdump). Bei
convenience-Software, umso mehr solcher mir Security-Implikationen
hab ich da deutlich mehr schlechtes Gewissen ;)

/ralph

[Claus Reibenstein]

Post by Ralph Aichinger
Was ist die allgemeine Meinung hier zu run0, dem sudo-Ersatz von
systemd?

Ich sehe keinen Anlass, sudo durch run0 zu ersetzen. Meine Scripte
benutzen sudo, und das sollen sie auch weiterhin tun. Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Gruß
Claus

[Christian Garbs]

Mahlzeit!

Post by Claus Reibenstein

Post by Ralph Aichinger
Was ist die allgemeine Meinung hier zu run0, dem sudo-Ersatz von
systemd?

Ich sehe keinen Anlass, sudo durch run0 zu ersetzen. Meine Scripte
benutzen sudo, und das sollen sie auch weiterhin tun. Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Wirkt sich das denn dann automatisch auf Deine Skripte aus
oder muss in jedes Skript noch ein "source ~/.bash_aliases" rein?

Ich meine, dass Aliase und Shellfunktionen (zumindest per default)
nicht exportiert werden.

Gruß
Christian

[Marc Haber]

Post by Claus Reibenstein
Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Was wäre denn dieser Notfall?

Grüße
Marc

[Dietz Proepper]

Post by Marc Haber

Post by Claus Reibenstein
Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Was wäre denn dieser Notfall?

Wenn Poettering und seine Jungs $irgendwas basteln, was sudo so
sabotiert, dass run0 die einzige Möglichkeit wird?

[Marc Haber]

Post by Dietz Proepper

Post by Marc Haber

Post by Claus Reibenstein
Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Was wäre denn dieser Notfall?

Wenn Poettering und seine Jungs $irgendwas basteln, was sudo so
sabotiert, dass run0 die einzige Möglichkeit wird?

That's not going to happen.

[Dietz Proepper]

Post by Marc Haber

Post by Dietz Proepper

Post by Marc Haber

Post by Claus Reibenstein
Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Was wäre denn dieser Notfall?

Wenn Poettering und seine Jungs $irgendwas basteln, was sudo so
sabotiert, dass run0 die einzige Möglichkeit wird?

That's not going to happen.

Fool me once, fool me twice usw..

[Alexander Schreiber]

Post by Marc Haber

Post by Dietz Proepper

Post by Marc Haber

Post by Claus Reibenstein
Notfalls baue ich
ein "alias sudo=run0" in mein .bash_aliases ein.

Was wäre denn dieser Notfall?

Wenn Poettering und seine Jungs $irgendwas basteln, was sudo so
sabotiert, dass run0 die einzige Möglichkeit wird?

That's not going to happen.

Famous last words.

SCNR,
Alex.

[Friedemann Stoyan]

Post by Ralph Aichinger
Was ist die allgemeine Meinung hier zu run0, dem sudo-Ersatz von
systemd?

Grundsätzlich kann ich die Idee dahinter nachvollziehen. Jedoch finde ich,
dass ein Punkt noch gar nicht angesprochen wurde. Nämlich dass die
Autorisierung per polkit erfolgen soll. Ich habe keine Ahnung von Polkit. Aber
wenn ich mir z.B. https://wiki.archlinux.org/title/Polkit anschaue, habe ich
den Eindruck, dass das Framework nicht gerade einfach und intuitiv ist. Wieder
ein Framework mehr, mit dem ich mich auseinandersetzen muss.


mfg Friedemann

[Ralph Aichinger]

Post by Friedemann Stoyan
Grundsätzlich kann ich die Idee dahinter nachvollziehen. Jedoch finde ich,
dass ein Punkt noch gar nicht angesprochen wurde. Nämlich dass die
Autorisierung per polkit erfolgen soll. Ich habe keine Ahnung von Polkit.

Ja, guter Punkt. Wenn ich auf meinem Laptop run0 aufrufe, dann kommt die
Passwortabfrage nicht im Terminalfenster, sondern als GUI-Popup. Ich hab
es noch zu wenig verwendet, um für mich zu sagen, ob das gut oder
schlecht ist.

Post by Friedemann Stoyan
Aber
wenn ich mir z.B. https://wiki.archlinux.org/title/Polkit anschaue, habe ich
den Eindruck, dass das Framework nicht gerade einfach und intuitiv ist. Wieder
ein Framework mehr, mit dem ich mich auseinandersetzen muss.

Das stimmt natürlich, andererseits ist es für Gnome-Nutzer kein neues
Framework. Die Frage ist. wie run0 auf einem reinen CLI-Server tut, ob
man da auch immer Polkit braucht.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Friedemann Stoyan
Grundsätzlich kann ich die Idee dahinter nachvollziehen. Jedoch finde ich,
dass ein Punkt noch gar nicht angesprochen wurde. Nämlich dass die
Autorisierung per polkit erfolgen soll. Ich habe keine Ahnung von Polkit.

Ja, guter Punkt. Wenn ich auf meinem Laptop run0 aufrufe, dann kommt die
Passwortabfrage nicht im Terminalfenster, sondern als GUI-Popup. Ich hab
es noch zu wenig verwendet, um für mich zu sagen, ob das gut oder
schlecht ist.

Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

Grüße
Marc

[Ralph Aichinger]

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

So:

***@surface:~$ run0 ls
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

/ralph

[Marcel Mueller]

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Echt jetzt?

OK, das braucht kein Mensch. Ich meine sudo & Co ist je gerade für die
Skript-Welt. Die Klicki-Bunti UIs halten die Berührungslinie zu
Kommandozeile ja ohnehin klein. Da ist es weitgehend egal, welches Tool
im Hintergrund schafft, weil man die Änderung nicht bemerkt.


Marcel

[Alexander Schreiber]

Post by Marcel Mueller

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Echt jetzt?
OK, das braucht kein Mensch. Ich meine sudo & Co ist je gerade für die
Skript-Welt. Die Klicki-Bunti UIs halten die Berührungslinie zu
Kommandozeile ja ohnehin klein. Da ist es weitgehend egal, welches Tool
im Hintergrund schafft, weil man die Änderung nicht bemerkt.

Interessierte Frage an Leute, die sich mit halbwegs aktuellem
Windows auskennen: Wenn man "runas" auf der Shell benutzt[0], kommt
die Passwortabfrage dann als Textprompt in der Shell oder als GUI-
Popup?

Man liest sich,
Alex.
[0] Hier nix Windows, sonst hätte ich es ausprobiert.

[Marc Haber]

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

=> ich werde auch weiterhin Arbeit in sudo stecken müssen.

Da bin ich ganz "zuversichtlich".

Grüße
Marc

[Stefan+ (Stefan Froehlich)]

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Geil. Und wofür braucht man das Ding dann überhaupt?

Servus,
Stefan

[Tim Ritberg]

Post by Stefan+ (Stefan Froehlich)

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Geil. Und wofür braucht man das Ding dann überhaupt?

Pötterings Weltherrschaft. ;-)

"Guck mal Mama, was ich gemacht hab..."

scnr

Tim

[Alexander Schreiber]

Post by Stefan+ (Stefan Froehlich)

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Geil. Und wofür braucht man das Ding dann überhaupt?

Chronisches Hammer-Syndrom: Wenn das einzige Werkzeug das man kennt,
ein Hammer ist, dann sieht jedes Problem aus wie ein Nagel.

SCNR,
Alex.

[Ralph Aichinger]

Post by Stefan+ (Stefan Froehlich)

Post by Ralph Aichinger
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Geil. Und wofür braucht man das Ding dann überhaupt?

Wohlgemerkt, das passiert wenn man kein Passwort eingibt. Sonst schaut
es so aus:

***@surface:~/foobar$ run0 ls
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password:
==== AUTHENTICATION COMPLETE ====
bar Downloads
***@surface:~/foobar$

Wobei die Zeile nach "Authenication complete", also die eigentliche
Programmausgabe, rot hinterlegt ist.

/ralph

[Stefan+ (Stefan Froehlich)]

Post by Ralph Aichinger

Post by Stefan+ (Stefan Froehlich)

Post by Ralph Aichinger
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure

Geil. Und wofür braucht man das Ding dann überhaupt?

Wohlgemerkt, das passiert wenn man kein Passwort eingibt. Sonst schaut
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
==== AUTHENTICATION COMPLETE ====
bar Downloads

Ach menno, also geht's ja eh. Damit hast Du offenbar nicht nur mich,
sondern so ziemlich alle hier erfolgreich zum Narren gehalten :-)

Post by Ralph Aichinger
Wobei die Zeile nach "Authenication complete", also die
eigentliche Programmausgabe, rot hinterlegt ist.

Huch. Das müsste man abstellen...

Und wenn man das Äquivalent zum unsäglichen "sudo su -" eingibt,
also "run0 su -", ist dann alles weitere rot hinterlegt?

Sevus,
Stefan

[Ralph Aichinger]

Post by Stefan+ (Stefan Froehlich)
Und wenn man das Äquivalent zum unsäglichen "sudo su -" eingibt,
also "run0 su -", ist dann alles weitere rot hinterlegt?

Wenn schon, dann run0 sudo su -

Und ja ;)

/ralph

[Alexander Schreiber]

Post by Ralph Aichinger

Post by Marc Haber
Wie sieht das aus wenn man das Kommando innerhalb einer ssh-Session
aufruft?

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Ralph Aichinger,,, (ralph)
Password: Failed to start transient service unit: Connection timed out
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
/ralph

Ah, "Nicht unterstützter Anwendungsfall" auch bekannt als "Du hältst
run0 falsch, Dein Problem".

SCNR,
Alex.

[Alexander Goetzenstein]

Hallo,

Post by Ralph Aichinger
Was ist die allgemeine Meinung hier zu run0, dem sudo-Ersatz von
systemd?

meine "allgemeine" Meinung ist, dass ich generell Distributionen meide,
auf denen ich nicht direkt root sein kann. Und wie ich in ein
Verzeichnis wechsle, in dem ich mehr als einen Befehl abzusetzen habe,
nutze ich gern
sudo su -
um wenigstens nach der Anmeldung die Arbeit zu erleichtern, wenn es denn
schon mal sein muss. Diesen Wegfall der direkten Anmeldung als root
empfinde ich ohnehin als nannyhaft bevormundend, und es erschwert die
Arbeit. Wenn ich mir selbst und meiner Sorgfalt nicht über den Weg
traue, kann ich ja sudo nutzen, aber es nutzen zu müssen, geht mir gegen
den Strich.

Was run0 daran noch verbessern soll, ist mir nicht so ganz eingängig.
Mit der Konfiguration über die sudoers komme ich klar, mehr Berührung
habe ich damit nicht. Aus Erfahrungen der Vergangenheit fürchte ich
aber, dass es eher nicht besser werden wird. Wenn es nur um einen
1:1-Austausch des Aufrufs von sudo durch run0 ginge, verstünde ich den
Aufwand nicht, aber das wird es wohl nicht sein.

[Ralph Aichinger]

Post by Alexander Goetzenstein
meine "allgemeine" Meinung ist, dass ich generell Distributionen meide,
auf denen ich nicht direkt root sein kann.

Gibt es solche?

Post by Alexander Goetzenstein
Und wie ich in ein
Verzeichnis wechsle, in dem ich mehr als einen Befehl abzusetzen habe,
nutze ich gern
sudo su -

Warum nicht einfach "sudo -i"?

Post by Alexander Goetzenstein
um wenigstens nach der Anmeldung die Arbeit zu erleichtern, wenn es denn
schon mal sein muss. Diesen Wegfall der direkten Anmeldung als root
empfinde ich ohnehin als nannyhaft bevormundend, und es erschwert die
Arbeit.

Er trägt aber zur Sicherheit bei (Angreifer kommt weniger leicht zu
erhöhten Privilegien, bzw. muß sich noch mal anstrengen). Und im
beruflichen Umfeld mit mehreren Leuten erhöht es die Zurechenbarkeit
(wer war es, der mit erhöhten Rechten ganz /var gelöscht hat ;).

Post by Alexander Goetzenstein
Was run0 daran noch verbessern soll, ist mir nicht so ganz eingängig.
Mit der Konfiguration über die sudoers komme ich klar, mehr Berührung
habe ich damit nicht. Aus Erfahrungen der Vergangenheit fürchte ich
aber, dass es eher nicht besser werden wird. Wenn es nur um einen
1:1-Austausch des Aufrufs von sudo durch run0 ginge, verstünde ich den
Aufwand nicht, aber das wird es wohl nicht sein.

Auch sudo ist in manchen Situationen noch einigermaßen problematisch,
sehr schnell hat da jeder, der ein bißchen mehr tun muß root. Oft will
man das gar nicht, darum hat das Weiterentwickeln solcher Konzepte
durchaus Sinn. Viel feingliedriger als "alle Rechte/darf fast nix" geht
mit sudo IMHO nicht.

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger

Und wie ich in ein Verzeichnis wechsle, in dem ich mehr als einen
Befehl abzusetzen habe, nutze ich gern
sudo su -

Warum nicht einfach "sudo -i"?

um wenigstens nach der Anmeldung die Arbeit zu erleichtern, wenn es denn
schon mal sein muss. Diesen Wegfall der direkten Anmeldung als root
empfinde ich ohnehin als nannyhaft bevormundend, und es erschwert die
Arbeit.

Er trägt aber zur Sicherheit bei (Angreifer kommt weniger leicht zu
erhöhten Privilegien, bzw. muß sich noch mal anstrengen).

Davon bin ich nicht überzeugt.

Post by Ralph Aichinger
Und im beruflichen Umfeld mit mehreren Leuten erhöht es die
Zurechenbarkeit

Das stimmt, aber nur, wenn man es auch auf per-Kommando-Basis verwendet.
Wenn jeder einfach »sudo -i« aufruft, dann weiß man erst wieder nicht,
wer was gemacht hat. Da kann man sich dann auch gleich als Root
einloggen.

Post by Ralph Aichinger
(wer war es, der mit erhöhten Rechten ganz /var gelöscht hat ;).

Inklusive dem Logfile, in dem stand, wer es war. (Sorry für's
Witzkaputtmachen).

Post by Ralph Aichinger

Was run0 daran noch verbessern soll, ist mir nicht so ganz eingängig.

Es könnte einfacher sein. Ist aber eher nicht zu erwarten.

Post by Ralph Aichinger
Auch sudo ist in manchen Situationen noch einigermaßen problematisch,
sehr schnell hat da jeder, der ein bißchen mehr tun muß root. Oft will
man das gar nicht, darum hat das Weiterentwickeln solcher Konzepte
durchaus Sinn. Viel feingliedriger als "alle Rechte/darf fast nix" geht
mit sudo IMHO nicht.

Doch, das geht schon. Du kannst genau festlegen, welche User welche
Kommandos mit welchen Privilegien ausführen dürfen.

Nur muss man dafür halt die 3537 Zeilen lange Man-Page von sudoers(5)
durchlesen, die auch nicht so strukturiert ist, dass man das, was man
sucht, schnell findet (zumindest für "man" = "ich").

Meine Antwort auf sudo war vor über 20 Jahren xssd
<https://www.hjp.at/programs/xssd/>. Da passt die Man-Page auf eine
A4-Seite und der Source-Code ist (inklusive Kommentare) weniger als 400
Zeilen C. Deckt aber IMHO alle »statischen« Anwendungsfälle ab. Ist aber
meines Wissens in keiner Distribution (ich bin einfach schlecht im
Marketing).

hp

[Ralph Aichinger]

Post by Peter J. Holzer

Post by Ralph Aichinger
Er trägt aber zur Sicherheit bei (Angreifer kommt weniger leicht zu
erhöhten Privilegien, bzw. muß sich noch mal anstrengen).

Davon bin ich nicht überzeugt.

Beispiel: Login per ssh-Key ohne Superuser-Rechte, um höhere Rechte zu bekommen,
muß man das Passwort eingeben. Da braucht man schon mal u.U. Key+Passwort um
weiterzukommen.

Post by Peter J. Holzer
Das stimmt, aber nur, wenn man es auch auf per-Kommando-Basis verwendet.
Wenn jeder einfach »sudo -i« aufruft, dann weiß man erst wieder nicht,
wer was gemacht hat. Da kann man sich dann auch gleich als Root
einloggen.

Auch dann kann man sich oft aus den Zeiten was zusammenreimen (wenn 10
Minuten vorher XY "sudo -i" macht, und sich vorher 3 Tage lang keiner
eingeloggt hat, wer wird wohl verantwortlich sein?).

Außerdem kann man sich eventuell mit dem Audit-Log was zusammenpuzzeln.

Wenn sich jemand als "root"/rootpasswort einloggt, dann wird es halt
unvergleichlich schwieriger. Da muß man dann vermutlich von der IP oder
irgendwelchen Manierismen des Users ausgehen.

Post by Peter J. Holzer
Doch, das geht schon. Du kannst genau festlegen, welche User welche
Kommandos mit welchen Privilegien ausführen dürfen.

Ich hab mal wo gearbeitet, wo viel mit Docker gemacht wurde, und es sehr
schwer war die Grenze zwischen "darf alles" und "kann nix mehr sinnvoll
mit Docker zu machen" zu ziehen.

Post by Peter J. Holzer
Meine Antwort auf sudo war vor über 20 Jahren xssd
<https://www.hjp.at/programs/xssd/>. Da passt die Man-Page auf eine
A4-Seite und der Source-Code ist (inklusive Kommentare) weniger als 400
Zeilen C. Deckt aber IMHO alle »statischen« Anwendungsfälle ab. Ist aber
meines Wissens in keiner Distribution (ich bin einfach schlecht im
Marketing).

Hm, interessant, aber ja, tendentiell bist du nicht gut im Marketing,
ich hab heut das erste mal davon gehört.

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger

Post by Peter J. Holzer

Post by Ralph Aichinger
Er trägt aber zur Sicherheit bei (Angreifer kommt weniger leicht zu
erhöhten Privilegien, bzw. muß sich noch mal anstrengen).

Davon bin ich nicht überzeugt.

Beispiel: Login per ssh-Key ohne Superuser-Rechte, um höhere Rechte zu
bekommen, muß man das Passwort eingeben. Da braucht man schon mal u.U.
Key+Passwort um weiterzukommen.

Das zusätzliche Passwort bräuchte man bei su auch (in diesem Fall halt
das Root-Passwort). Ist das sicherer oder weniger sicher? Wenn ein
Angreifer meinen private Key hat, ist die Wahrscheinlichkeit, dass er
auch mein Passwort kennt, schon recht hoch. Das Root-Passwort hingegen
ist ein anderes. Andererseits steigt die Gefahr eines Leaks, wenn
mehrere Leute das Root-Passwort kennen. Und in beiden Fällen kann
jemand, der bereits Zugriff auf den Account hat, das Passwort mit hoher
Wahrscheinlichkeit abfangen. Also viel Unterschied sehe ich da nicht.

Gegenüber direktem Login als Root hat man einen Faktor mehr. Stimmt.
Aber ein Passwort ist in dem Szenario ein eher schwacher Faktor. Und ssh
könnte man z.B. über einen Yubikey absichern, das würde IMHO mehr
bringen (habe ich aber noch nicht ausprobiert).

Post by Ralph Aichinger

Post by Peter J. Holzer
Das stimmt, aber nur, wenn man es auch auf per-Kommando-Basis verwendet.
Wenn jeder einfach »sudo -i« aufruft, dann weiß man erst wieder nicht,
wer was gemacht hat. Da kann man sich dann auch gleich als Root
einloggen.

Auch dann kann man sich oft aus den Zeiten was zusammenreimen (wenn 10
Minuten vorher XY "sudo -i" macht, und sich vorher 3 Tage lang keiner
eingeloggt hat, wer wird wohl verantwortlich sein?).

Das geht bei SSH auch. Wenn die Leute entsprechend kurzlebige Sessions
haben. Bei Leuten, die sich gewohnheitsmäßig kurz nach dem Reboot
einloggen und dann bis zum nächsten Reboot eingeloggt bleiben (eventuell
mit screen), hast Du in beiden Fällen verloren.

Post by Ralph Aichinger
Außerdem kann man sich eventuell mit dem Audit-Log was zusammenpuzzeln.
Wenn sich jemand als "root"/rootpasswort einloggt, dann wird es halt
unvergleichlich schwieriger. Da muß man dann vermutlich von der IP oder
irgendwelchen Manierismen des Users ausgehen.

Key Hash. Ist mindestens so eindeutig wie ein Username. Und von den
Usern, die sich als Root einloggen dürfen, sollte man die Hashes kennen.

Post by Ralph Aichinger

Post by Peter J. Holzer
Doch, das geht schon. Du kannst genau festlegen, welche User welche
Kommandos mit welchen Privilegien ausführen dürfen.

Ich hab mal wo gearbeitet, wo viel mit Docker gemacht wurde, und es sehr
schwer war die Grenze zwischen "darf alles" und "kann nix mehr sinnvoll
mit Docker zu machen" zu ziehen.

Das liegt dann aber an Docker und nicht an sudo.

hp

[Ralph Aichinger]

Post by Peter J. Holzer
auch mein Passwort kennt, schon recht hoch. Das Root-Passwort hingegen
ist ein anderes. Andererseits steigt die Gefahr eines Leaks, wenn
mehrere Leute das Root-Passwort kennen. Und in beiden Fällen kann

Vor allem auch die große Hemmschwelle beim Verdacht eines Leaks das
Root-Passwort zu ändern. Wenn man eine gemeinsame Passwortdatenbank hat,
dann geht es ja noch, aber wenn man z.B. 3 Leute verständigen muß, dass
man aus Grund XY das Rootpasswort vom Server Z geändert hat, dann ist
das oft so eine große logistische und psychologische Hürde, dass es
in der Praxis oft unterbleibt. Ich hab mal in einer Firma gearbeitet, da
hat man entlang diverser Passwortstrategien abschätzen können, wie lange
Root-Passwörter schon nicht mehr geändert worden sind. Das ware etliche
Jahre, in denen viele Kollegen die es gekannt haben ausgeschieden sind.

Post by Peter J. Holzer
jemand, der bereits Zugriff auf den Account hat, das Passwort mit hoher
Wahrscheinlichkeit abfangen. Also viel Unterschied sehe ich da nicht.

Das erfordert zumindest minimal mehr Wissen, und hinterläßt u.U. auch
mehr Spuren.

Post by Peter J. Holzer
Gegenüber direktem Login als Root hat man einen Faktor mehr. Stimmt.
Aber ein Passwort ist in dem Szenario ein eher schwacher Faktor. Und ssh
könnte man z.B. über einen Yubikey absichern, das würde IMHO mehr
bringen (habe ich aber noch nicht ausprobiert).

Natürlich. Aber dazu muß eine Organisation von selbst nur 3 oder 4
Leuten erst mal bereit sein.

Post by Peter J. Holzer
Das geht bei SSH auch. Wenn die Leute entsprechend kurzlebige Sessions
haben. Bei Leuten, die sich gewohnheitsmäßig kurz nach dem Reboot
einloggen und dann bis zum nächsten Reboot eingeloggt bleiben (eventuell
mit screen), hast Du in beiden Fällen verloren.

Ja, nur bei "root" als Login (das man IMHO zu recht bei ssh sperrt) ist
das halt noch mal blöder.

Post by Peter J. Holzer
Das liegt dann aber an Docker und nicht an sudo.

Klar, nur mit dem ganzen systemd-Zeug, eventuell Podman oder was auch
immer, besteht die Hoffnung, dass sich *das* Problem dann angehen läßt.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Peter J. Holzer
auch mein Passwort kennt, schon recht hoch. Das Root-Passwort hingegen
ist ein anderes. Andererseits steigt die Gefahr eines Leaks, wenn
mehrere Leute das Root-Passwort kennen. Und in beiden Fällen kann

Vor allem auch die große Hemmschwelle beim Verdacht eines Leaks das
Root-Passwort zu ändern. Wenn man eine gemeinsame Passwortdatenbank hat,
dann geht es ja noch, aber wenn man z.B. 3 Leute verständigen muß, dass
man aus Grund XY das Rootpasswort vom Server Z geändert hat, dann ist
das oft so eine große logistische und psychologische Hürde, dass es
in der Praxis oft unterbleibt. Ich hab mal in einer Firma gearbeitet, da
hat man entlang diverser Passwortstrategien abschätzen können, wie lange
Root-Passwörter schon nicht mehr geändert worden sind. Das ware etliche
Jahre, in denen viele Kollegen die es gekannt haben ausgeschieden sind.

Ich glaube es gibt mehr als fünf Firmen, in denen ich das universelle
Root-Passwort niemals benötigt und auch niemals ungehasht gesehen
habe. Und das ist gut so.

Grüße
Marc

[Ralph Aichinger]

Post by Marc Haber
Ich glaube es gibt mehr als fünf Firmen, in denen ich das universelle
Root-Passwort niemals benötigt und auch niemals ungehasht gesehen
habe. Und das ist gut so.

Ja. Aber oft reichen schon ein, zwei Leute im Team die das anders sehen.

/ralph

[Peter J. Holzer]

Post by Marc Haber

Post by Ralph Aichinger

Das Root-Passwort hingegen ist ein anderes. Andererseits steigt die
Gefahr eines Leaks, wenn mehrere Leute das Root-Passwort kennen.

Vor allem auch die große Hemmschwelle beim Verdacht eines Leaks das
Root-Passwort zu ändern. Wenn man eine gemeinsame Passwortdatenbank hat,
dann geht es ja noch, aber wenn man z.B. 3 Leute verständigen muß, dass
man aus Grund XY das Rootpasswort vom Server Z geändert hat, dann ist
das oft so eine große logistische und psychologische Hürde, dass es
in der Praxis oft unterbleibt.

[...]

Post by Marc Haber
Ich glaube es gibt mehr als fünf Firmen, in denen ich das universelle
Root-Passwort niemals benötigt und auch niemals ungehasht gesehen
habe. Und das ist gut so.

Auf unserem TU-Institut hatten wir (vor 30+ Jahren) das Root-Passwort in
einem zugeklebten Kuvert hinterlegt. Im Normalfall sollte man das nie
brauchen, weil wir für alle Routine-Tätigkeiten entweder die Permissions
entsprechend gesetzt oder setuid-Wrapper geschrieben hatten (sudo
kannten wir damals nicht). Falls doch, wussten die üblichen
Verdächtigen, wo das Root-Passwort zu finden war. Policy war, dass man
nach Gebrauch das Root-Passwort geändert und in einem frischen Kuvert
(außen mit Datum versehen und unterschrieben) hinterlegt hat.

(Jetzt, wo ich darüber nachdenke, weiß ich nicht mehr, wie wir ein
einheitliches Root-Passwort auf allen Workstations implementiert hatten.
Haben wir das tatsächlich über YP verteilt?)

hp

[Marc Haber]

Post by Peter J. Holzer

Post by Marc Haber
Ich glaube es gibt mehr als fünf Firmen, in denen ich das universelle
Root-Passwort niemals benötigt und auch niemals ungehasht gesehen
habe. Und das ist gut so.

Auf unserem TU-Institut hatten wir (vor 30+ Jahren) das Root-Passwort in
einem zugeklebten Kuvert hinterlegt. Im Normalfall sollte man das nie
brauchen, weil wir für alle Routine-Tätigkeiten entweder die Permissions
entsprechend gesetzt oder setuid-Wrapper geschrieben hatten (sudo
kannten wir damals nicht). Falls doch, wussten die üblichen
Verdächtigen, wo das Root-Passwort zu finden war. Policy war, dass man
nach Gebrauch das Root-Passwort geändert und in einem frischen Kuvert
(außen mit Datum versehen und unterschrieben) hinterlegt hat.

Genau, so kenne ich das auch. Gerne auch die eine Hälfte bei
Führungskraft A, die andere bei Führungskraft B. Wurde nie gebraucht,
weil alle sudo hatten und es einfach war, einen Rechner neu
aufzusetzen.. Ein bisschen gegenseitiges Vertrauen muss auch sein.

Grüße
Marc

[Marc Haber]

Post by Alexander Goetzenstein
meine "allgemeine" Meinung ist, dass ich generell Distributionen meide,
auf denen ich nicht direkt root sein kann.

Was sind das für Distributionen und wie verhindern sie das?

Post by Alexander Goetzenstein
Und wie ich in ein
Verzeichnis wechsle, in dem ich mehr als einen Befehl abzusetzen habe,
nutze ich gern
sudo su -

sudo -i wäre zu einfach oder zu wenig cool?

Post by Alexander Goetzenstein
um wenigstens nach der Anmeldung die Arbeit zu erleichtern, wenn es denn
schon mal sein muss. Diesen Wegfall der direkten Anmeldung als root
empfinde ich ohnehin als nannyhaft bevormundend, und es erschwert die
Arbeit. Wenn ich mir selbst und meiner Sorgfalt nicht über den Weg
traue, kann ich ja sudo nutzen, aber es nutzen zu müssen, geht mir gegen
den Strich.

Jedes mal sudo vorne dran zu schreiben erzeugt einen netten Audit
Trail und die Dokumentation in DEINER Shellhistory anstelle der von
root. Das hat durchaus Vorteile.

Und ja, auf Red Hat Systemen ist das wegen enger zugezogener
Directorypermissions lästig.

Post by Alexander Goetzenstein
Was run0 daran noch verbessern soll, ist mir nicht so ganz eingängig.

Es kommt halt ohne suid aus. Ob die neuen Mechanismen so viel besser
sind, müssen Leute mit Ahnung entscheiden deren Nerven noch nicht
blank liegen.

Grüße
Marc

[Alexander Goetzenstein]

Hallo,

Post by Marc Haber
sudo -i wäre zu einfach oder zu wenig cool?

nö, es ist schlicht egal. Oder meinst Du, dass man so zwei
Tastenanschläge spart? Vielleicht gewöhne ich es mir ja noch an...

[Marc Haber]

Post by Alexander Goetzenstein

Post by Marc Haber
sudo -i wäre zu einfach oder zu wenig cool?

nö, es ist schlicht egal. Oder meinst Du, dass man so zwei
Tastenanschläge spart? Vielleicht gewöhne ich es mir ja noch an...

Es ist auch ein Prozess weniger. Ich weiß nicht warum ich so denke,
aber für mich ist sudo su - ein Indikator von "ich weiß nicht genau
was ich da tue".

Grüße
Marc