Benutzerrechte auf Ordner & Dateien?

[Pummeluff]

Sinnvoll wäre eigentlich:

• Nutzer "admin" löschen, weil überflüssig.
• Nutzer "x-worf": Entweder trägst du den in die Gruppe sudo ein, was du bei admin schon gemacht hast.
• Alternativ Nutzer "x-worf": trägst du in die Gruppe wheel und wechselst bei Bedarf in der Konsole mit su - zu Root.
• Mit weiteren Nutzern kannst du gern rumspielen. Würde ich an Deiner Stelle aber erst mal weglassen.

Grundsätzlich ist auch möglich, dass auch andere Personen den Desktop mit eigenen Nutzern benutzen werden. Und dann wäre es schon gut, die eigenen Dateien schützen zu können (zumindest maximal Leserechte).

Das ist die Defaulteinstellung (Dateien: 0644, Verzeichnisse: 0755). Siehe dazu auch umask, ist ebenfalls definiert in /etc/login.defs.

Ich denke, du verrennst Dich zu sehr in irgendwelchen Details, die du jetzt noch nicht brauchst. Du musst da keine Wissenschaft daraus machen.

 

[rgbs]

Die Annahme ist, dass es grundsätzlich sicherer sei einen Nutzer ohne "Systemverwalter"-Rechte im Alltag zu nutzen.

Also bei Linux ist das halt anders als bei Windows geregelt.
Bei Fedora als Voreinstellung:
Es gibt den Benutzer root, aber dieser kann sich nicht anmelden (weil sein Passwort leer ist).
Es wird bei der Installation ein Nutzer angelegt welcher Mitglied der Gruppe wheel ist.
Wenn dieser Nutzer mit dem Rechner arbeitet, hat er keinerlei Rechte auf Dateien welche root gehören schreibend zuzugreifen. Er kann nur Dateien ändern, welche ihm auch gehören.
Wenn nun Aufgaben anstehen bei denen auf Dateien welche root gehören zugegriffen werden muss, holt sich der Benutzer über sudo eine ich nenne es mal Vollmacht, um nach eingeben seines Passwortes root Rechte zu haben. Diese Vollmacht ist aber normalerweise nur kurze Zeit (Minutenbereich) gültig.
Ein zweiter Nutzer bringt also sicherheitstechnisch gar nichts, weil ja auch der erste Nutzer, wenn er nicht zeitlich begrenzt mit Vollmacht unterwegs ist, auch nichts am System ändern kann.

Alternativ Nutzer "x-worf": trägst du in die Gruppe wheel und wechselst bei Bedarf in der Konsole mit su - zu Root.

Also ich lasse aus rein sicherheitstechnischen Überlegungen das root Passwort leer und arbeite über sudo -i mit einer rootshell wenn im Terminal viele administrative Aufgaben erledigt werden müssen.
Ich gehe nämlich davon aus, dass die Leute bei Redhat und Canonical wissen, was sie tun.
Wenn ich nur mal so selbst überlege, auf jedem Linuxrechner heißt Cheffe root, böse Buben müssen also nur noch das Passwort ich nenne es mal ausbaldowern.

Gruß
R.G.

 

[foofoobar]

Also bei Linux ist das halt anders als bei Windows geregelt.
Bei Fedora als Voreinstellung:
Es gibt den Benutzer root, aber dieser kann sich nicht anmelden (weil sein Passwort leer ist).

Auch hier lohnt ein Blick in die Manpage:

encrypted password
Refer to crypt(3) for details on how this string is interpreted.
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unixpassword to log in (but the user may log in the system by other means).

This field may be empty, in which case no passwords are required to authenticate as the specified login name. However, some applications which read the/etc/shadow file may decide not to permit any access at all if the password field is empty.

A password field which starts with a exclamation mark means that the password is locked. The remaining characters on the line represent the password fieldbefore the password was locked.

https://linux.die.net/man/5/shadow

 

[X-Worf]

Also ich ging davon aus, dass die Felder mit rotem Text bearbeitet werden müssen und habe dementsprechend Root aktiviert und ein PW vergeben, wie auch einen Nutzer mit wheel samt Pw angelegt (hier „admin“). Siehe Bilder der Fedora 41 KDE Installation.

Ergänzung (Sonntag um 11:19)

Sinnvoll wäre eigentlich:

• Nutzer "admin" löschen, weil überflüssig.
• Nutzer "x-worf": Entweder trägst du den in die Gruppe sudo ein, was du bei admin schon gemacht hast.

Was ist dann der Unterschied, abgesehen von der Benennung? Diese hatte ich im Endeffekt von der Installations-GUI abgeleitet.

Ergänzung (Sonntag um 11:58)

Das ist die Defaulteinstellung (Dateien: 0644, Verzeichnisse: 0755). Siehe dazu auch umask, ist ebenfalls definiert in /etc/login.defs.

Aber nun habe ich die Einstellungen bzw. Berechtigungen für den Ordner "Dokumente" ja entsprechend #20 (Bild 3) angepasst, sodass alle Nutzer Vollzugriff haben. Dementsprechend hat auch Nutzer "vier" nun Schreibrechte.

Von daher ist doch eigentlich @madmax2010 Vorschlag der Beste (?).

1. Ich lege z.B. eine neue Gruppe an.
2. ausgewählte Nutzer werden der Gruppe hinzugefügt.
3. dem gewünschten Verzeichnis, samt aller weiteren Daten darin, teile ich der Gruppe zu.

(Diese spontane Idee muss ich aber nochmal mit den ganzen Infos hier abgleichen.

EDIT: glaube 2. funktioniert nicht wie gedacht, weil ein Nutzer immer in einer Gruppe Mitglied sein kann? )

---

Mal als Notiz:

Spoiler: Fehlversuch

(Gruppe anlegen:)
sudo adduser projekt

(dann auslesen:)
less /etc/group

(führt zu:)
admin:x:1000:
benny:x:1001:
drei:x:1002:
vier:x:1003:
projekt:x:1004:

(Gruppe "projekt" ist vorhanden)

Nutzer einer Gruppe hinzufügen:
(#14 verstehe ich hier nicht ganz)

sudo usermod -a -G projekt drei

sudo usermod -a -G projekt vier

Nutzer eine Gruppe auslesen:

cat /etc/group

projekt:x:1004:drei,vier

Verzeichnisse zum Testen anlegen

mkdir /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonAdmin

mkdir /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier

Berechtigungen des Verzeichnisses über GUI ändern:
siehe Bilder

PAVA (ProjektAngelegtVonAdmin):
Hier komme ich dann nicht mehr weiter. Vielleicht verstehe ich etwas nicht, oder die GUI funkionert nicht, oder müsste rebooten zwischendurch? Vielleicht liegt es auch am Nutzer "admin" der das Verzeichnis angelegt hat.

PAVV
Hier kommt eine Fehlermeldung eingeloggt als Nutzer "vier", aber immerhin kann ich "projekt" auswählen, wäre da nicht die Fehlermeldung.

Ich glaube mit der GUI komme ich hier nicht weiter. Einloggen als root (sudo -i) samt root-PW hat funktioniert (nur unter "admin, was logisch ist) aber bringt der GUI wohl keine weiteren Rechte. Das Die Rechteverwaltung von Verzeichnis PAVV ist unter "admin" weitläufig ausgegraut.

Die Hilfe aus #14 funktioniert leider auch nicht:

admin@Terra:~$ chgrp projekt /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegt
VonVier
chgrp: die Gruppe von '/ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVie
r' wird geändert: Die Operation ist nicht erlaubt
admin@Terra:~$

Aber natürlich mit sudo

admin@Terra:~$ sudo chgrp projekt /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAng
elegtVonVier
[sudo] Passwort für admin:
admin@Terra:~$

Endlich passt die Gruppe (Bild: PAVV mit Gruppe projekt)

Und Nutzer drei hat in PAVV Schreibrechte. (Textdatei angelegt)

---

Hier mache ich erstmal einen Cut und teste demnächst aus, wie es sich von Daten aus ~home von "drei" und "vier" verhält die ins Verzeichnis "PAVV" kopiert werden.

Vielen Dank an Alle, die hier helfen! 👍
Ich antworte vielleicht nicht immer direkt auf Alles, aber lese es aufmerksam und versuche es anzuwenden, sobald ich es verstehe.

---

Wie ich gerade sehe, wurde durchs Anlegen der Gruppe "projekt" auch eine Nutzer "projekt" angelegt. Interessant.... dann bin ich wohl doch noch auf dem Holzweg und muss mir z.B. #14 wieder genauer anschauen.

---

Nach einem Reboot war alles wieder hinfällig!?

 

[rgbs]

Also ich ging davon aus, dass die Felder mit rotem Text bearbeitet werden müssen und habe dementsprechend Root aktiviert und ein PW vergeben,

Also ich hab das eben mal in VMs geübt.
Bei Fedora Gnome, wird man bei der Installation gar nicht nach Name und Passwort gefragt, sondern muss den Namen und das Passwort des users beim erstem Start eingeben.
Bei Fedora KDE wird vor der Installation nach Name und Passwort des users gefragt, und das rot unterlegte Feld "Administrator deaktiviert" wechselt von rot zu o.k. wenn man Name und Passwort des users eingegeben hat.
Das ist meiner Ansicht nach bei Fedora KDE etwas inkonsequent geregelt, wenn man einerseits hier:
https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/ schreibt "aus Sicherheitsgründen ist root deaktiviert" aber andererseits bei der Installation das Aktivieren von root anbietet.

Gruß
R.G.

 

[X-Worf]

Man kann das entweder über das setgid-Bit oder über ACLs regeln. Da ACLs bei 2 Nutzern etwas über das Ziel hinausschießen, erklär ich mal kurz das Vorgehen mit Setgid:

0. Annahmen

• Nutzer A: user_a, Gruppe users
• Nutzer B: user_b, Gruppe users
• Wir wollen ein gemeinsames Verzeichnis shared auf externer Platte, die nach /mnt/ext/ gemountet ist.
• Wir arbeiten für die Einrichtung als Root!. Alternativ klemmt halt der "Adminnutzer" vor jeden Befehl ein sudo.

1. Gruppe users prüfen
Je nach Distribution landen angelegte User nicht in der Gruppe users, sondern bekommen als Gruppenname eine dem Nutzer gleichlautende Gruppe. Das kann man prüfen mit:

id user_a

# Fall 1: Gruppe user ist zugeordnet: Dann mit 2. weitermachen
uid=1000(user_a) gid=100(users)

# Fall 2: Nutzerbezogene Gruppe: Dann hier weiter
uid=1000(user_a) gid=1000(user_a)

Fall 2:
Wir müssen die beiden Nutzer in die gemeinsame Gruppe users eintragen.

gpasswd -a user_a users
gpasswd -a user_b users

2. Verzeichnis anlegen und konfigurieren

mkdir /mnt/ext/shared

# Wir ändern die Gruppe des Verzeichnisses auf users
chgrp users /mnt/ext/shared

# Rechte: Jeder Gruppennutzer darf reinschreiben. Und die Rechte sollen vererbt werden.
chmod 2775 /mnt/ext/shared

Damit sollten beide Nutzer im gemeinsamen Verzeichnis alle dort erstellten Dateien bearbeiten können. Die Lösung hier ist der saubere Unix-Weg.

In meinem Fall möchte ich ein internes Laufwerkt nutzen.

Gemäß deiner Anleitung klappt es natürlich (internes Laufwerk & für Nutzer "drei" und "vier"):

admin@Terra:~$ sudo gpasswd -a drei users
[sudo] Passwort für admin:
Benutzer drei wird zur Gruppe users hinzugefügt.
admin@Terra:~$ sudo gpasswd -a vier  users
Benutzer vier wird zur Gruppe users hinzugefügt.
admin@Terra:~$ id drei
uid=1002(drei) gid=1002(drei) Gruppen=1002(drei),100(users),1004(projekt)
admin@Terra:~$ id vier
uid=1003(vier) gid=1003(vier) Gruppen=1003(vier),100(users),1004(projekt)
admin@Terra:~$ sudo chgrp users /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$ sudo chmod 2775 /ef84d8a8-fe6b-49a9-ad2d-391a71238091/ProjektAngelegtVonVier
admin@Terra:~$

Aber so wirklich habe ich es noch nicht verstanden.

Vor allem, warum ist die die Gruppe "users" so entscheidend bzw. warum geht es nur so bzw. am besten so?

Aber dementsprechend sollte ich vielleicht besser die Daten, die sonst jeweils in ~home landen, direkt in einem gemeinsam Verzeichnis anlegen und bearbeiten.

Ich bin mir nur noch nicht sicher, was bzgl. Zugriffsrechte passiert, wenn ich das gemeinsam Verzechnis dann z.B. auf 4TB kopiere. Vermutlich muss ich dort dann auch wieder chgrp und chmod durchführen?

Und was bedeutet das, wenn diese Daten dann wiederrum auf einem externen Laufwerk (exFAT) landen, um es an iPadOS, WinOS bearbeiten zu können?
(ich glaube Nichts, da es dort keine Rechteverwaltung gibt)

Wenn ich Daten von der Externen auf das dritte, interne Laufwerk "4TB" kopiere ist es ja dann wie "Anlegen" innerhalb des Verzeichnisses, sofern ich es mit Nutzer "drei" und "vier" mache. (Gemäß jetziger Testumgebung)

Grundsätzlich muss ich also drauf achten, dass alle Daten, die ich hin und her schiebe immer mit den passenden Nutzern (mindestens Mitglied "users" und passenden Zugriffsrechten (des Verzeichnisses) verarbeite?

 

[Pummeluff]

warum ist die die Gruppe "users" so entscheidend bzw. warum geht es nur so bzw. am besten so?

Eigentlich muss es nicht users sein. Du könntest auch eine andere Gruppe dafür erstellen. Allerdings ist users allein aus historischen Gründen auf jedem Linux schon vorhanden. Das war/ist die Standardgruppe, die früher jeder User als primäre Gruppe hatte. Deswegen auch die gid=100.

Und was bedeutet das, wenn diese Daten dann wiederrum auf einem externen Laufwerk (exFAT) landen, um es an iPadOS, WinOS bearbeiten zu können?
(ich glaube Nichts, da es dort keine Rechteverwaltung gibt)

Windows hat eine andere Rechteverwaltung, die nicht direkt kompatibel zur Unix-Rechteverwaltung ist. Die Rechte kannst du unter Linux nicht verwenden.

Beim Mounten von Windows-Dateisystemen gibst du explizit den Usernamen, die Gruppe und die Umask mit an. Alle Dateien gehören dann temporär diesem einen Nutzer. Entsprechend ist die o.g. Konfiguration der Rechte sinnlos bzw. funktioniert auf diesem Dateisystem nicht. Siehe dazu auch exFAT - Dateiattribute und Sicherheit

Grundsätzlich muss ich also drauf achten, dass alle Daten, die ich hin und her schiebe immer mit den passenden Nutzern (mindestens Mitglied "users" und passenden Zugriffsrechten (des Verzeichnisses) verarbeite?

Ja. Durch das setgid-Attribut verlagerst du das Recht von Nutzer auf die Gruppe und vererbst das auch. Normalerweise bekommen neu angelegte Dateien die Rechte 0644. D.h. die Gruppe und andere dürfen lesen, aber nicht schreiben. Durch das setgid-Attribut beim aktuellen Verzeichnis erhält eine angelegte Datei das Rechte 2664. D.h. die Dateien können unterschiedlichen Nutzern gehören. Aber alle Nutzer derselben Gruppe dürfen in der Datei rumschreiben.

 

[X-Worf]

Ok, vielen Dank erstmal!

Diese Seite hilft mir das alles besser zu verstehen: https://chmodcommand.com/ zusammen mit den anderen geposteten Links, wie z.b. die wiki.

Das ist also das was über die GUI nicht geklappt hat.
So langsam komme ich glaube ich rein.

Kannst du nochmal auf meine Frage in #24, zweiter Block eingehen? (Warum "admin" löschen und "x-worf" mit sudo erweitern, bzw. den Nutzen/Unterschied)

(Denn irgendwann werde ich das Testsystem hier löschen und dann komplett von Vorne und hoffentlich richtig neu aufsetzen)

---

Weils irgendwie zur Thematik passt:

Warum hat addgroup dazu geführt, dass auch ein gleichnamiger user nach dem reboot angelegt wurde? (Grobe Einordnung wäre interessant)

---

Also ich hab das eben mal in VMs geübt.
Bei Fedora Gnome, wird man bei der Installation gar nicht nach Name und Passwort gefragt, sondern muss den Namen und das Passwort des users beim erstem Start eingeben.
Bei Fedora KDE wird vor der Installation nach Name und Passwort des users gefragt, und das rot unterlegte Feld "Administrator deaktiviert" wechselt von rot zu o.k. wenn man Name und Passwort des users eingegeben hat.
Das ist meiner Ansicht nach bei Fedora KDE etwas inkonsequent geregelt, wenn man einerseits hier:
https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/ schreibt "aus Sicherheitsgründen ist root deaktiviert" aber andererseits bei der Installation das Aktivieren von root anbietet.

Gruß
R.G.

Kann sein, dass mir das bei der Installation auch so auffiel, mir dann komisch vorkam und ich den Prozess nochmal neu gestartet hatte, um das root-pw festlegen zu können.

Aber warum inkonsequent?
Wenn ich root mit "sudo -i" aktiviere, würde doch ansonsten die Aufforderung auftauchen ein PW zu vergeben (laut dem Video). Dann ist doch besser gleich während der Installation ein sicheres PW zu erstellen, dass man sich zu so einem Zeitpunkt auch vernünftig notiert.

"Deaktiviert" heißt nicht, dass es nicht angelegt wird, entsprechend deines Links.

 

[Pummeluff]

Warum "admin" löschen und "x-worf" mit sudo erweitern, bzw. den Nutzen/Unterschied

Die Grundproblematik ist, dass du irgendwie eine Rechteeskalation brauchst (Übergang von normalem Nutzer zu Root). Dafür gibt's mehrere Möglichkeiten.

Früher hat man dafür su genutzt, um in einer Konsole zum Root-Nutzer zu wechseln. Das Risiko dabei ist, dass du mit einem Keylogger das Root-Passwort auslesen könntest.

Deswegen hat Canonical vor ca. 20 Jahren sudo für diese Aufgabe "missbraucht". sudo ist eigentlich dafür da, einen Befehl im Kontext eines anderen Nutzers auszuführen. Das muss nicht zwangsläufig root sein. sudo setzt man eigentlich auf Multinutzersystemen ein, auf denen die (menschlichen) Nutzer eben keine Root-Rechte haben, aber Befehle von z.B. technischen Nutzern ausführen müssen.

Vorteil der Sudo-Methode: Du benötigst kein Root-Passwort und hast damit theoretisch einen Sicherheitsgewinn gegenüber su. Nachteil ist der inflationäre Einsatz von sudo und dass du auch keine Trennung in der Konsole hast. Ich hab für Adminaufgaben meist eine Root-Konsole offen, die dann aber auch nur für Adminaufgaben genutzt wird. Ganz böse wird's bei der Sudo-Methode, wenn die Eingabe des Passwortes sogar deaktiviert ist:

user_a ALL=NOPASSWD: ALL

Damit wird der normale Nutzer praktisch zum Root-Nutzer.

In Deinem Fall: Dein Admin-Nutzer ist ein normaler Nutzer, der durch Rechteeskalation zu Root wird. Du holst Dir damit einen geringfügigen Sicherheitsgewinn durch eine umständlichere Arbeitsweise, da du Dich immer über 2 Nutzer durchhangelst. Wenn du Dich damit wohlfühlst, ist das ok. Ich halte es nicht für notwendig.

Warum hat addgroup dazu geführt, dass auch ein gleichnamiger user nach dem reboot angelegt wurde?

Kann ich Dir nicht mal erklären. Üblich auf jedem System sind useradd und groupadd. adduser und addgroup gibt es nicht überall. Die beiden Befehle sind Wrapper mit teilweise anderen/zusätzlichen Optionen.

 

[rgbs]

Wenn ich root mit "sudo -i" aktiviere, würde doch ansonsten die Aufforderung auftauchen ein PW zu vergeben (laut dem Video). Dann ist doch besser gleich während der Installation ein sicheres PW zu erstellen, dass man sich zu so einem Zeitpunkt auch vernünftig notiert.

Mit sudo -i aktivierst nicht root, sondern Du bekommst eine Vollmacht mit root Rechten zu arbeiten.
Bei sudo -i musst Du nicht das root Passwort eingeben, sondern Dein user Passwort.

Gruß
R.G.

 

[foofoobar]

Mit sudo -i aktivierst nicht root, sondern Du bekommst eine Vollmacht mit root Rechten zu arbeiten.
Bei sudo -i musst Du nicht das root Passwort eingeben, sondern Dein user Passwort.

Ich hatte das hier schon mal auseinander gefummelt.
root ist root weil 0 != 0 falsch ist.

 

[rgbs]

root ist root weil 0 != 0 falsch ist.

Wenn ich z.B. bei einer Bank eine Kontovollmacht vorlege, werde ich von denen behandelt wie der Vollmachtgeber.
Fakt ist nun mal, dass man bei sudo -i mit root Rechten arbeiten kann ohne dass root aktiviert wurde.

Vorteil der Sudo-Methode: Du benötigst kein Root-Passwort und damit theoretisch einen Sicherheitsgewinn gegenüber su.

eben !!!
Zu sudo und su:
https://www.linux-community.de/ausgaben/linuxuser/2004/02/zu-befehl-su-sudo/

Gruß
R.G.

 

[foofoobar]

Wenn ich z.B. bei einer Bank eine Kontovollmacht vorlege, werde ich von denen behandelt wie der Vollmachtgeber.
Fakt ist nun mal, dass man bei sudo -i mit root Rechten arbeiten kann ohne dass root aktiviert wurde.

Ich kenne keine Möglichkeit root zu deaktivieren.
Und kommen die ganzen Prozesse die als root laufen her wenn root doch angeblich deaktiviert werden kann?

ps aux | grep ^root | grep -v '\]$'

 

[X-Worf]

Hatte das falsch interpretiert...

admin@Terra:~$ sudo -i
[sudo] Passwort für admin:
root@Terra:~# "passwort123"
bash: "passwort123": Befehl nicht gefunden...
root@Terra:~# exit
Abgemeldet
admin@Terra:~$

"passwort123" ist natürlich nicht das Passwort... (und musste dort auch gar nicht eingegeben werden).

 

[rgbs]

Ich kenne keine Möglichkeit root zu deaktivieren.

Immer Deine wenig zielführende Erbsenzählerei.
https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/
"Aus Sicherheitsgründen ist das root-Konto auf Fedora Workstations standardmäßig deaktiviert."
Das Linux ohne root nicht laufen würde ist doch eh klar.

Gruß
R.G.

 

[foofoobar]

Immer Deine wenig zielführende Erbsenzählerei.

Ein bisschen root ist so wie ein bisschen schwanger.

 

[X-Worf]

Kann ich Dir nicht mal erklären. Üblich auf jedem System sind useradd und groupadd. adduser und addgroup gibt es nicht überall. Die beiden Befehle sind Wrapper mit teilweise anderen/zusätzlichen Optionen.

Hatte mich vertan und vorhin vertippt. Ich hatte tatsächlich mit sudo adduser projekt einen Nutzer angelegt, obwohl ich nur eine Gruppe anlegen wollte.

Jetzt nochmal richtig ausprobiert mit groupadd (Fedora Docs) wurde auch nur die Gruppe projekt2 angelegt.

Ganz böse wird's bei der Sudo-Methode, wenn die Eingabe des Passwortes sogar deaktiviert ist:

user_a ALL=NOPASSWD: ALL

Damit wird der normale Nutzer praktisch zum Root-Nutzer.

Das heißt, das würde passieren, wenn ich bei der Installation "Root deaktivieren" auswähle? Oder ist das wieder ein anderer Zusammenhang?
(vgl. #24, Bild2)

Und in Bezug zu #25: Sollte ich bei einer Neuinstallation einfach nur den Benutzer (mit wheel) anlegen, damit die Maske (#24, Bild1) bzgl "Root-Konto" nicht mehr rot ist?

So würde dann alles ausreichend gut angelegt? Und ich würde z.B. auf weitere Nutzer verzichten...

Du holst Dir damit einen geringfügigen Sicherheitsgewinn durch eine umständlichere Arbeitsweise, da du Dich immer über 2 Nutzer durchhangelst. Wenn du Dich damit wohlfühlst, ist das ok. Ich halte es nicht für notwendig.

..um diesen Rat zu folgen.

 

[rgbs]

Das heißt, das würde passieren, wenn ich bei der Installation "Root deaktivieren" auswähle?

natürlich nicht.
https://docs.fedoraproject.org/de/quick-docs/getting-started-guide/
mal lesen !!!

Gruß
R.G.

 

[X-Worf]

Danke für die Aufklärung!
Gelesen habe ich das schon. Hatteste ja auch schonmal gepostet. Aber die sudo/root-Thematik ist eben auch noch komplett neu. Da kann ich von dem Text nicht die technische Umsetzung ableiten, obwohl es offenbar mit mehr Wissen völlig logisch erscheint.^^

 

[rgbs]

Und in Bezug zu #25: Sollte ich bei einer Neuinstallation einfach nur den Benutzer (mit wheel) anlegen, damit die Maske (#24, Bild1) bzgl "Root-Konto" nicht mehr rot ist?

So würde dann alles ausreichend gut angelegt? Und ich würde z.B. auf weitere Nutzer verzichten...

Das ist so wie ich das sehe der schlauste Plan.

Gruß
R.G.