Hallo,
wie bekomme ich bei Leap 16.0 wieder das bekannte Verhalten für “sudo” konfiguriert?
Mit “visudo” habe ich eine sudoers in /etc angelegt, aber da gibt es noch “subgid” und “subuid”.
Die letzten Beiden sind mir neu und vermutlich für das neue sudo-Verhalten verantwortlich …?
Nun möchte ich aber gern, dass ich bei “sudo” eben nicht noch irgendein PW angeben muss.
Was kann ich tun?
Danke euch vorab 
Ich habe da vor einiger Zeit für Myrlyn einiges Material zusammengetragen:
Bei Tumbleweed / Slowroll / Leap 16.0 gibt es auch ein Paket sudo-policy-wheel-auth-self, das einige Konfigurationsschnipsel für so etwas enthält:
% rpm -ql sudo-policy-wheel-auth-self
/usr/etc/sudoers.d/50-wheel-auth-self
/usr/share/polkit-1
/usr/share/polkit-1/rules.d
/usr/share/polkit-1/rules.d/51-wheel.rules
% sudo cat /usr/etc/sudoers.d/50-wheel-auth-self
Defaults:%wheel !targetpw
%wheel ALL = (root) ALL
Bei Leap 16.0 wird der erste Benutzer (den du bei der Installation anlegst) automatisch in die wheel-Benutzergruppe eingetragen; in meinem Fall der Benutzer “sh”:
% whoami
sh
% grep '^wheel' /etc/group
wheel:x:494:sh
Der bekommt nach den Regeln oben Root-Rechte für sudo. Damit muß ich - weil das diese Regel !targetpw so angibt - mein eigenes Paßwort eingeben, nicht das von root.
Aber auch das nervt (mich genauso wie dich), also habe ich zusätzlich noch das hier in meiner /etc/sudoers (man könnte es auch in ein /etc/sudoers.d/50-no-pw eintragen), damit ich per Default kein Paßwort eingeben muß:
#
# Added 2025-06-16 sh:
#
# Per-terminal timeout (in minutes) before asking the password again; default: 5 min
# sudo -K to reset the timestamp for the current terminal so it asks again
Defaults timestamp_timeout=2
# Defaults timestamp_timeout=0
# Ask for the root password
Defaults targetpw
# Only for the wheel group: Ask for the user's password
Defaults: %wheel !targetpw
Defaults env_reset
Defaults: %wheel env_keep = "DISPLAY WAYLAND_DISPLAY XAUTHORITY XDG_RUNTIME_DIR QT_QPA_PLATFORMTHEME QT_ENABLE_HIGHDPI_SCALING"
# Allow root privileges for members of the 'wheel' user group
# %wheel ALL=(ALL:ALL) ALL
## Same thing without a password
%wheel ALL=(ALL:ALL) NOPASSWD: ALL
# Force asking for a password for 'myrlyn' and 'myrlyn-sudo'
# %wheel ALL=(root) PASSWD: /usr/bin/myrlyn
# %wheel ALL=(root) PASSWD: /usr/bin/env
# Allow root privileges for this one user (without password)
# sh ALL=(ALL) NOPASSWD: ALL
# Defaults: sh !syslog, !pam_session
Defaults !log_allowed
Damit kann ich das weitreichend konfigurieren:
Normalerweise kein Paßwort für die gesamte wheel-Benutzergruppe:
%wheel ALL=(ALL:ALL) NOPASSWD: ALL
An alle Security-Experten, die bei sowas einen Anfall bekommen: Kriegt euch wieder ein; nagelt einfach nicht per Default jedes System so zu, daß es unbenutzbar wird!
Um die normale sudo-Umgebung mit Paßwort für Myrlyn zu testen, habe ich noch ein paar Ausnahmen konfiguriert, die normalerweise auskommentiert sind, damit ich mein eigenes Programm auch benutzen kann, ohne wahnsinnig zu werden:
# %wheel ALL=(root) PASSWD: /usr/bin/myrlyn
# %wheel ALL=(root) PASSWD: /usr/bin/env
Man kann so etwas für jedes Kommando separat konfigurieren. Aber bloß nicht übertreiben, sonst wird es ganz schnell zu kompliziert.
Wie inzwischen generell üblich, ist die bevorzugte Methode, eigene Änderungen in eigenen Schnipseln in eine Datei in /etc/sudoers.d zu schreiben, die dann in der angegebenen Reihenfolge (10-abc, 20-def, …) ausgeführt werden. Dann kann man sowas nach Sinn und Zweck getrennt halten und auch irgendwo archivieren (git/GitHub!).
/etc/sudoers geht aber immer noch; darin gibt es ein %include, das die Dateien in /etc/sudoers.d ausführt. In /etc sind jetzt deine Konfigurationsdateien; die des Systems sind jetzt in /usr/etc/, für sudo also /usr/etc/sudoers.d. Aber deine werden danach ausgeführt, überschreiben also die Systemvorgaben.
Falls du noch Fragen hast, nur zu.
Wenn jemand von außen durch meine FritzBox reinkommt und dann auch noch meine Maschine findet und sich dort einloggen kann, haben bereits mehrere Levels von Sicherheit komplett versagt. Und sonst ist in meinem LAN / WLAN niemand.
In einer Behörde mit jeder Menge Client-PCs und Servern ist das was völlig anderes. Aber hierzulande wird ja bei jeder Gelegenheit das Kind mit dem Bad ausgeschüttet; deshalb kommt es auch so solchem Irrsinn wie SELinux oder vorher AppArmor. Lieber ständiges DoS als Augenmaß…
WOW! Was für ein Statement.
Eigentlich könnte man sich zurücklehnen und sagen: “Jeder ist seines Glückes Schmied.”
Das Dumme ist nur, dass viele von denen, die so eine Einstellung haben, allzu oft (unwissentlich) der Cyberkriminalität Vorschub leisten (z. B. indem ihre ungeschützten Konten, Rechner, … von Dritten für kriminelle Machenschaften genutzt werden).
Vielen Dank Ich schau mir das in Ruhe an.
@susejunky
ich glaube, du schreibst hier gerade nicht zu meiner Frage => ergo: lass es
Wie wäre es damit sudo überhaupt nicht zu benutzen?
Es ist auf System die ich verwalte nicht installiert und hoffe das auf Leap 16.0 vort zu setzen.
Was benutzt du dann stattdessen?
Das wäre dann, wie jetzt - egal was ich als User tun will, muss ich IMMER mein User-PW eingeben - und das nervt mich.
Ich habe ein paar Befehle dem User via sudoers zur PWfreien Nutzung gegeben.
Exakt das meine ich mit “das Kind mit dem Bad ausschütten”. Du hast schon gelesen, daß es hier um die Ausführung von einzelnen Kommandos mit sudo geht, oder?
Es geht nicht darum, Benutzerkonten allgemein ungeschützt zu lassen; nicht um Einloggen ohne Paßwort oder irgendsoetwas. Um überhaupt so weit zu kommen, sudo zu benutzten, muß man es geschafft haben, sich in die Maschine einzuloggen. Natürlich muß man das absichern; das steht hier überhaupt nicht zur Debatte. Aber ich muß nicht im Minutentakt immer wieder beweisen, daß ich (in meinem Home-Office, wo sonst niemand ist!) auch tatsächlich ich bin.
Ich würde auch sehr gern bei Benutzung von “sudo” wieder das root-PW eingeben müssen und nicht mein User-PW.
Kann man das auch wieder so hinbekommen?
Klar: Das ist die Regel mit targetpw (also das PW des sudo-Zielbenutzers eingeben) bzw. !targetpw (also NICHT das PW des Zielbenutzers eingeben).
!targetpw hat den Vorteil, daß man niemandem das root-PW geben muß; das ist insbesondere dann praktisch, wenn man einem Benutzer Rechte für z.B. Drucker-Kommandos geben will, aber nicht alles sonst. Dann muß man aber natürlich auch diese Kommandos genau aufführen, oder auf eine Benutzergruppe beschränken.
Deswegen ist auch targetpw der Default für alle anderen in der Konfiguration oben: Mit dem Root-PW kann man sowieso einfach mit su oder su - Root-Rechte bekommen, oder sich schlicht und einfach als root einloggen.
su -
Seit über 40 Jahre.
Und KDE > Menu > Terminal - Super user mode bringt das in einem Klick.
Nein. Immer Passwort von root. Dan tut man was man als Systembetreuer tun soll. Dan exit (oder Ctrl-D).
Password:
boven:~ #
Aber Jeder nach Wunsch.
install
Generate new/old rights for sudoers
cat > my-sudoers << EOF
Defaults targetpw
ALL ALL = (ALL) ALL
EOF
install -Dm 0644 my-sudoers %{buildroot}%{_sysconfdir}/sudoers.d/my-sudoers
Generate old login.defs, so user group is users again.
cat > my-login.defs << EOF
USERGROUPS_ENAB = no
EOF
install -Dm 0644 my-login.defs %{buildroot}%{_sysconfdir}/login.defs.d/my-login.defs
Soweit würde ich gar nicht gehen wollen, aber danke.
Das kann ich mir entsprechend anpassen.
Ich schau mir die entsprechenden Möglichkeiten an.
Danke für eure Ideen
btw. @hcvv
su - nutze ich durchaus auch häufig, aber eben gern auch mal sudo für immerwiederkehrende kleine Sachen, die aber root-Rechte erfordern …
So stand/steht es bei 15.6 drin.
Ja stimmt. Habe ich auch gerade gesehen.
Aber ich muß nicht im Minutentakt immer wieder beweisen, daß ich (in meinem Home-Office, wo sonst niemand ist!) auch tatsächlich ich bin.
Das “klassische” sudo-Verhalten, das ich bevorzuge (Eingabe root-Passwort bei sudo), sorgt aber auch dafür, dass dem User vor dem Abschicken von Kommandos, die die OS-Installation betreffen, eben dies bewusst gemacht wird.
Alleine dadurch, daß man vor den eigentlichen Befehl sudo schreiben muß, wird einem ja bewußt gemacht, daß man dafür Root-Rechte braucht, also besonders gut überlegen muß, was man da tut.
übrigens im Gegensatz zu einem Shell-Fenster, in dem man etwas wie su - laufen hat, wie man das früher so gemacht hat. Und wenn der Prompt noch so grell rot ist: Eine offene Root-Shell verführt dazu, einfach da drin weiterzumachen und sich nicht strikt auf die Befehle zu beschränken, für die man wirklich zwingend Root-Rechte braucht.