doas + /sbin

[MrNicNac]

Ich habe gesehen dass in Bullseye doas verfügbar ist und habe es gleich mal installiert und sudo runter geschmissen.

Funktioniert alles super, allerdings eine Kleinigkeit wäre da:

Code: Alles auswählen

# Funktioniert:
doas /sbin/reboot

# Funktioniert NICHT:
doas reboot

Code: Alles auswählen

$ printenv | grep PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

$ doas printenv | grep PATH
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Bei doas gibt es die Option setenv, siehe man doas.conf.

Ich denke mal damit würde sich das Problem lösen lassen?
Oder auch nicht? Denn /usr/sbin ist ja bereits in PATH, siehe oben.

Das hier funktioniert (wie erwartet) auch nicht:

Code: Alles auswählen

# /etc/doas.conf
permit setenv { PATH=/usr/sbin:$PATH } user as root

Irgendwelche Ideen?
Dank im Voraus

[fischig]

Ich kenne doas nicht. Aber ich weiß auch nicht, warum man das als einfacher Benutzer für ein reboot bemühen will: Neustarten darf jeder Benutzer (merkwürdigerweise ) das System, und zwar direkt. Etwas anderes wäre es wohl, wenn du mittels doas ein Root vorbehaltenes Kommando ausführen willst. Dann müsste das wohl irgendwo und irgendwie dateimäßig festgehalten werden, dass Root(!) das einem Benutzer erlauben will.

[MSfree]

Neustarten darf jeder Benutzer (merkwürdigerweise ) das System, und zwar direkt.

Das ist nicht ganz richtig. Von der graphischen Umgebung darfst du die Kiste runterfahren, weil das PolicyKit das so einrichtet. Mittels SSH-Login oder schlicht von der Textkonsole darfst du es nicht.

[mcb]

Ich habe gesehen dass in Bullseye doas verfügbar ist und habe es gleich mal installiert und sudo runter geschmissen.
................


Irgendwelche Ideen?
Dank im Voraus

Du kannst etwas wie:

Code: Alles auswählen

permit nopass marc cmd reboot

in die doas.conf setzen (testweise) führt dazu das alle ausführbaren Dateien die reboot heißen mit rootrechten laufen (ohne Paßwort).

Oder du bastelst dir einen alias - dann stört der absolute path nicht - ist auch sicherer.

[smutbert]

Neustarten darf jeder Benutzer (merkwürdigerweise ) das System, und zwar direkt.

Das ist nicht ganz richtig. Von der graphischen Umgebung darfst du die Kiste runterfahren, weil das PolicyKit das so einrichtet. Mittels SSH-Login oder schlicht von der Textkonsole darfst du es nicht.

Das ist nicht ganz richtig. Lokal von der graphischen Umgebung oder schlicht der Textkonsole darfst du die Kiste runterfahren, weil das policykit so einrichtet. Mittels SSH-Login darfst du es nicht.


(Wobei ich nicht gewusst habe, dass da policykit im Spiel ist, ich dachte, das macht systemd-logind ganz alleine.)

[willy4711]

Code: Alles auswählen

# Funktioniert:
doas /sbin/reboot

Wie schon gesagt wurde, ist das PolicyKit für derartige Aktionen verantwortlich.
deshalb funktionieren auch:

Code: Alles auswählen

~$ /sbin/poweroff

Code: Alles auswählen

~$ /sbin/reboot

oder

Code: Alles auswählen

~$ systemctl poweroff

oder

Code: Alles auswählen

~$ systemctl reboot

Und zwar alles ganz ohne dieses sinnfreie sudo oder hier gar doas

Vielleicht erst mal über das policykit-1 informieren

Zu lesen in der Datei /usr/share/polkit-1/actions/org.freedesktop.login1.policy

Dann gibt es auch noch dieses magische su oder gar su - (wg. $PATH)

Sollte man auch mal probieren

[unitra]

Hier funktioniert das reboot mit doas. Aber die Konfiguraiton sieht so aus:

Code: Alles auswählen

permit nopass :wheel

Die wheel group ist bei debian nicht vorhanden, also muß die eingerichtet werden

https://wiki.debian.org/SystemGroups

Hier die MAN page für doas

https://man.openbsd.org/doas.conf.5

[mcb]

Hier funktioniert das reboot mit doas. Aber die Konfiguraiton sieht so aus:

Code: Alles auswählen

permit nopass :wheel

Die wheel group ist bei debian nicht vorhanden, also muß die eingerichtet werden

https://wiki.debian.org/SystemGroups

Hier die MAN page für doas

https://man.openbsd.org/doas.conf.5

Doas geht auch ohne die Group wheel.

[willy4711]

Mich würde mal interessieren welchen Zweck dieses doas haben soll.
Vielleicht liege ich falsch, aber ein

Code: Alles auswählen

permit nopass :wheel

öffnet doch jeden uneingeschränkt Zugang zu Root -Rechten.
Denn der laufenden User wird ja dann wohl in der Gruppe wheel sein.

Soll ja jeder machen, wie er will. Aber für besonders sicher halte ich das nicht, zumal die Bordmittel von
Debian alle Möglichkeiten bieten, auch ohne sudo oder doas.

Oder geht es hier um ein System ohne GUI ? Dann wäre es eventuell nachzuvollziehen.

[MSfree]

Mich würde mal interessieren welchen Zweck dieses doas haben soll.

Das ist halt eine Alternative für sudo.

Ich halte aber nichts von Systemen, die neben su noch zahlreiche Nebeneingänge haben. Dazu zählen für mich eben sudo, polkit und doas. Das ist ja alles ganz niedlich, wenn das ein persönlicher Rechner ist, auf dem es genau einen Nutzer gibt, der ohnehin das root-Paßwort kennt. Im Multiuserbetrieb muß der Administrator aber den Überblick über solche Nebeneingänge behalten, und das wird umso schwieriger je mehr es davon gibt.

[mcb]

Mich würde mal interessieren welchen Zweck dieses doas haben soll.

Das ist halt eine Alternative für sudo.

Ich halte aber nichts von Systemen, die neben su noch zahlreiche Nebeneingänge haben. Dazu zählen für mich eben sudo, polkit und doas. Das ist ja alles ganz niedlich, wenn das ein persönlicher Rechner ist, auf dem es genau einen Nutzer gibt, der ohnehin das root-Paßwort kennt. Im Multiuserbetrieb muß der Administrator aber den Überblick über solche Nebeneingänge behalten, und das wird umso schwieriger je mehr es davon gibt.

Mit doas kann man (ich) sehr leicht nur ein zwei Programme für einzelne user freigeben. Per default ist alles gesperrt.

Braucht man es? Nun ja.

[willy4711]

Ich halte aber nichts von Systemen, die neben su noch zahlreiche Nebeneingänge haben. Dazu zählen für mich eben sudo, polkit und doas.

sudo hab ich bei mir eh nicht drauf. Lebe sehr gut mit dem PolKit.
Gefragt ist immer das Root-PW für das entsprechende Programm / Aktion ,
außer man modifiziert die entsprechende Policy.

Ich sehe daher nicht, dass das ein "Nebeneingang" ist.

Das Polkit regelt doch so gut wie alles in der GUI - soweit man eine hat.
Es ist standardmäßig installiert und m.E. in allen Oberflächen aktiviert.

Daher würde ich es eher als Haupteingang bezeichnen

[willy4711]

Mit doas kann man (ich) sehr leicht nur ein zwei Programme für einzelne user freigeben. Per default ist alles gesperrt.

Wie meinst du das (Per default) ?
Welche Programme denn z.B. ?

[MSfree]

Mit doas kann man (ich) sehr leicht nur ein zwei Programme für einzelne user freigeben.

Das geht mit polkit und sudo auch.

Per default ist alles gesperrt.

Solange du su, sudo und polkit ebenfalls auf deinem Rechner hast, stimmt die Aussage nicht, weil es eben noch 3 weitere Nebeneingänge gibt, die potentiell offen sind, um root-Rechte zu erlangen. Vor allem, wenn polkit und sudu mit den Standardeinstellungen betrieben werden.

[mcb]

Mit doas kann man (ich) sehr leicht nur ein zwei Programme für einzelne user freigeben. Per default ist alles gesperrt.

Wie meinst du das (Per default) ?
Welche Programme denn z.B. ?

Code: Alles auswählen

cat /etc/doas.conf 
permit :wheel cmd /usr/bin/apt

Ich habe das jetzt so. Mit sudo könnte ich das nicht so schnell umsetzen. Der Hauptbenutzer (also ich) darf per doas mit apt "arbeiten". 1000x einfacher als sudo zu konfigurieren.

[mcb]

Mit doas kann man (ich) sehr leicht nur ein zwei Programme für einzelne user freigeben.

Das geht mit polkit und sudo auch.

Per default ist alles gesperrt.

Solange du su, sudo und polkit ebenfalls auf deinem Rechner hast, stimmt die Aussage nicht, weil es eben noch 3 weitere Nebeneingänge gibt, die potentiell offen sind, um root-Rechte zu erlangen. Vor allem, wenn polkit und sudu mit den Standardeinstellungen betrieben werden.

Sorry ich meinte bei doas ist per default alles gesperrt. Das finde ich gut. Ja sudo habe ich nicht drauf. Immer noch zwei Nebeneingänge....

[TRex]

Schön, eure Unterhaltung über sudo und Alternativen. Ab wo soll ich die denn abtrennen, damit der TE mit seinem Problem auch wieder Aufmerksamkeit bekommt?

[willy4711]

Schön, eure Unterhaltung über sudo und Alternativen. Ab wo soll ich die denn abtrennen, damit der TE mit seinem Problem auch wieder Aufmerksamkeit bekommt?

Ist doch schon alles beantwortet.
Ich habe gesagt, dass man für reboot und poweroff kein doas braucht,
unitra hat eine Lösung für die config genannt.
mcb hat das erweitert.

Dann habe wir etwas "diskutiert"

Schlimm ? Nöö

[TRex]

Stimmt, sorry - das habe ich überlesen. Das passiert leider auch anderen desöfteren (bzw dann dem ebenso nicht immer aufmerksamen TE).

[fischig]

Von der graphischen Umgebung darfst du die Kiste runterfahren [...] schlicht von der Textkonsole darfst du es nicht.

Ich schon. Und sowohl Polkit als auch systemd ist bei mir (bis auf einer Maschine) nirgendwo installiert. Teste zwar gerade mit devuan beowulf, aber ich erinnere nicht, dass das bei irgendeiner Debian- Version anders wäre. Kann ich erst verifizieren, wenn ich wieder zu Hause bin. Und nebenbei: merkwürdig, bzw unlogisch im Vergleich zu shutdown fand ich's schon immer.

[ralli]

Doas habe nicht nur ich, sondern einige andere Communitymitglieder unter FreeBSd und OpenBSD eingesetzt und benutzt. Es kann zielgenau konfiguriert werden und stellt keinerlei Sicherheitsrisiko dar. Allerdings müßte ich auch wieder in die Manpage schauen, da ich es lange nicht benutzt habe. Ich wußte nicht, das es doas auch unter Linux gibt.

Gruß ralli

[mcb]

Von der graphischen Umgebung darfst du die Kiste runterfahren [...] schlicht von der Textkonsole darfst du es nicht.

Ich schon. Und sowohl Polkit als auch systemd ist bei mir (bis auf einer Maschine) nirgendwo installiert. Teste zwar gerade mit devuan beowulf, aber ich erinnere nicht, dass das bei irgendeiner Debian- Version anders wäre. Kann ich erst verifizieren, wenn ich wieder zu Hause bin. Und nebenbei: merkwürdig, bzw unlogisch im Vergleich zu shutdown fand ich's schon immer.

-im Terminal geht es (lokal) über ssh nicht. (Systemctl)

-shutdown und reboot sind für normale Anwender gesperrt (default).

[fischig]

-shutdown und reboot sind für normale Anwender gesperrt (default).

Möchtest du mich der Lüge bezichtigen? Das gälte dann für smutbert gleich mit.

Dein Beitrag ist sinnfrei.

[mcb]

-shutdown und reboot sind für normale Anwender gesperrt (default).

Möchtest du mich der Lüge bezichtigen? Das gälte dann für smutbert gleich mit.

Dein Beitrag ist sinnfrei.

Oh je ...

Code: Alles auswählen

marc@mb:~$ reboot
Command 'reboot' is available in the following places
 * /sbin/reboot
 * /usr/sbin/reboot
The command could not be located because '/sbin:/usr/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative privileges associated with your user account.
reboot: command not found
marc@mb:~$ 

^^ das ergeben die Voreinstellungen Und per ssh dürfen normale User per default keinen Reboot auslösen.

Ah

Code: Alles auswählen

marc@mb:~$ shutdown -r 0
Command 'shutdown' is available in the following places
 * /sbin/shutdown
 * /usr/sbin/shutdown
The command could not be located because '/usr/sbin:/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative privileges associated with your user account.
shutdown: command not found
marc@mb:~$ /usr/sbin/shutdown -r 120
Reboot scheduled for Sat 2021-09-11 23:32:17 CEST, use 'shutdown -c' to cancel.
marc@mb:~$ /usr/sbin/shutdown -c
marc@mb:~$ 

[smutbert]

Immer mit der Ruhe. Ich würde sagen hier will niemand ijemand einer Lüge bezichtigen, höchstens eines Irrtums und sinnfreie Beiträge werden hier auch nicht gepostet ☺

Zuerst war einmal nur die Rede davon, dass dank policykit ein lokal angemeldeter Benutzer das System herunterfahren und neustarten darf, egal ob auf der Textkonsole, z. B. mit den Befehlen

Code: Alles auswählen

$ systemctl poweroff
$ systemctl reboot

oder in der grafischen Oberfläche.

Die Befehle shutdown und reboot befinden sich allerdings in »/sbin« und sind damit normalerweise nicht im Suchpfad eines normalen Benutzers, aber den eigenen Suchpfad kann ein Benutzer selbst anpassen oder die Befehle einfach mit Pfad aufrufen

Code: Alles auswählen

/sbin/shutdown -h now
/sbin/reboot

mcbs Fehlermeldung ist da etwas irreführend. (Dafür dürfte command-not-found verantwortlich sein, das ich nicht auf dem Schirm hatte, weil ich das nie installiere.)

Jedenfalls sollte das so auch bei dir @mcb funktionieren.