openSUSE mit sudo und ohne root Account

Viele Distributionen wie Ubuntu, Debian, Fedora oder Arch Linux setzen inzwischen verpflichtend oder optional auf Benutzeraccounts mit erweiterten Rechte anstelle eines umfassenden root-Accounts. Auch mit openSUSE lässt sich so etwas umsetzen.

Ich arbeite mit einem ziemlich speziellen openSUSE-System. Ich habe das System sehr genau auf meine Bedürfnisse angepasst und ausgehend von einer minimalen Installation aufgebaut (das ist kein Arch-Spezifikum, auch wenn die Arch-Nutzer das manchmal glauben). Das System betreibe ich gänzlich ohne YaST und seit Neuestem mit systemd-homed.

Um das System besser an meine Bedürfnisse anzupassen, nutze ich zudem sudo anstelle eines root Accounts. Das ist bei openSUSE standardmäßig nicht vorgesehen, aber openSUSE ist eine sehr flexible und wenig dogmatische Distribution. Es erfordert aber einige Änderungen am System.

openSUSE auf sudo umstellen

Sudo einrichten

Zuerst muss man sudo installieren und konfigurieren:

# zypper in sudo

Anschließend ist sudo zu konfigurieren.

# EDITOR=nano visudo 

Zuerst entfernt man die SUSE-Standardkonfiguration, nach der sudo mit dem root-Account ausgeführt wird. Dazu müssen zwei Zeilen auskommentiert werden. Dazu setzt man ein # vor die Zeile. Das Ergebnis muss wie folgt aussehen:

#Defaults targetpw   # ask for the password of the target user i.e. root
#ALL   ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

Der Eintrag für die Gruppe wheel muss aktiv geschaltet werden (dazu das # vor der Zeile entfernen). Das Ergebnis muss wie folgt aussehen:

# Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL

Um grafische Programme mit sudo starten zu können sind zudem in folgender Zeile am Ende folgende zwei Ergänzungen zu machen. Die … stehen für die vielen Variablen dazwischen.

Defaults env_keep = "LANG ... DISPLAY XAUTHORITY"

Danach fügt man den Benutzeraccount, der mittels sudo erweiterte Rechte erhalten können soll, der Gruppe wheel hinzu. Bei einem herkömmlichen Benutzer geht das mit folgendem Befehl.

# usermod -aG wheel <benutzername>

Bei einem systemd-homed-Benutzer ist der Befehl anders:

# homectl update <benutzername> -G wheel

Hierbei unbedingt beachten, dass immer alle Gruppe genannt werden müssen, weil alle Gruppenmitgliedschaften überschrieben werden. Die Ausgabe könnte also wie folgt lauten:

# homectl update gheim -G vboxusers,users,wheel

Danach muss der Benutzer einmal ab- und wieder angemeldet werden. In der Konsole ist zu überprüfen, ob man mittels sudo entsprechende Befehle ausführen kann. Beispielsweise:

$ sudo zypper dup

Grafische Programme ohne root-Passwort starten

Manche Programme fragen beim Start das root-Kennwort ab. Beispielsweise YaST oder Programme wie der KDE-Partitionmanager. Unter KDE kann man das mit folgendem Befehl anpassen. Dazu wird eine entsprechende Konfiguration des Benutzers in ~/.config angepasst.

$ kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo

Root deaktivieren

Nun benötigt man den root-Account nicht mehr und kann ihn deaktivieren:

$ sudo passwd -l root

Sollte man ihn wieder benötigen, kann man ihn mit folgendem Befehl aktivieren:

$ sudo passwd -u root

Tipps & Tricks

Natürlich geht openSUSE in vielen Konfigurationen von der Existenz eines root-Accounts aus. Beispielsweise kann man keinen Drucker einrichten oder ändern, weil der Account mit sudo-Rechten nicht akzeptiert wird. Das lässt sich mit einer Änderung in der Datei /etc/cups/cups-files.conf ändern:

$ sudo nano /etc/cups/cups-files.conf

Hier ist folgender Eintrag zu suchen und wie folgt um die Gruppe wheel zu ergänzen:

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup wheel root

Benötigt man all das? Nein sicher nicht. Aber eine der Stärken von Linux ist, dass man sein System so einrichten kann, wie man es nutzen möchte. Mit diesem und anderen Artikeln möchte ich zeigen, wie mächtig openSUSE ist und dass es mindestens so flexibel und individuell konfiguriert werden kann, wie z. B. Arch Linux.

Cruiz
Cruizhttps://curius.de
Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.
  1. Danke für den Artikel.

    Wie Du selbst schreibst, benötigt man das nicht unbedingt. Es ist oprional möglich.
    Mich würde nur ehrlich interessieren, warum Du dast so nutzen möchtest?

    Ansonsten weiter so. Gerne mehr solche “how to” Artikel.

    Viele Grüße

    • Wie gesagt, primär natürlich Spielerei – gebe ich gerne zu 😉

      Persönlich bringt es mir nur einen Vorteil. Wenn ich mit einem klassischen root-Account arbeite, mache ich eine root-Shell auf und setze dort im Zweifelsfall auch Befehle ab, die nicht unbedingt root bräuchten, aber es ist praktisch für meinen Workflow (z. B. zypper se). Mit sudo bin ich da flexibler.

      Perspektivisch wird es interessant, wenn ich wirklich die Kubuntu-Systeme (siehe andere Artikel) in Richtung openSUSE umstellen möchte. Die Anwender habe ich jetzt über Jahre mühsam an das sudo-Konzept gewöhnt, da möchte ich jetzt nicht noch was Neues einführen.

  2. Auf meinem Laptop sind seit langem 2 Root Partitionen mit Leap und Debian Stable, die über die Jahre immer nur upgegraded wurden.
    Debian habe ich nach der Firefox Security Geschichte durch Fedora ersetzt, das mit Plasma Wayland wider Erwarten relativ problemlos läuft. Deshalb habe ich auch noch Leap 15.3 auf Tumbleweed mit Wayland upgegraded. Beide Systeme laufen noch auf Ext4, d. h. kein Snapper und kein Rollback. Auch mein Tumbleweed Plasma ist ziemlich minimal aufgesetzt, ich starte die User Session von der Console ohne SDDM.

    Warum ich das alles schreibe:
    In einer Fedora Plasma Session ist ein “sudo dnf upgrade” in der KDE Konsole hängen geblieben und hat eine inkonsistente RPM Datenbank hinterlassen, die nur mit viel Handarbeit wieder zu reparieren war. Vermutlich lag es daran, dass bei dem Upgrade die KDE Frameworks ausgetauscht wurden und es der Konsole sozusagen den Boden unter den Füßen weg gezogen hat. Administrator Rechte in einer graphischen Umgebung sind nicht immer eine gute Idee.

    Ein Tumbleweed Upgrade mit “zypper dup” mache ich grundsätzlich nur in der Root Console im multi-user.target mit möglichst wenig gestarteten Diensten. In der Regel ist sowieso ein Neustart nötig, weil auch Libraries ausgetauscht werden. Ich sehe auch überhaupt keinen Grund, mich dieser Möglichkeit freiwillig zu berauben, zumal sudo in letzter Zeit durch einige Sicherheitslücken aufgefallen ist. Es ist bei mir zwar installiert, ich verwende es aber nur gelegentlich, wenn ich aus einer User Session mal schnell Root Rechte brauche.

    • Sudo kann man doch auch außerhalb einer grafischen Umgebung im TTY verwenden? Dort meldet man sich halt zuerst mit seinem Benutzer an und nicht mit root. Ich sehe den Punkt hier daher nicht wirklich.

      • Natürlich kannst du als User “sudo zypper dup” statt als Root “zypper dup” ausführen.
        Aber wenn ich schon zur Administration die graphische Umgebung verlassen muss, kann ich mich auch gleich als Root anmelden. Diesen Punkt sehe ich nicht wirklich.

          • In der von dir beschriebenen Konfiguration kann man sudo immerhin mit dem User Passwort benutzen, d. h. der Administrator kann bestimmten Usern besondere Rechte zuweisen oder man deaktiviert den Root Account eben ganz.
            In der SUSE Default Konfiguration muss man das Root Passwort eingeben und da frage ich mich wirklich, wo der Unterschied zu “su -” ist.

Schreibe einen Kommentar zu Hans Antwort abbrechen

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Weitere Artikel