Caramon2 schrieb
Bleibt nur noch die Frage, was ich mit der Gruppe "disk" mache: Das brauche ich sehr oft, um Laufwerke direkt in KVM einzubinden.
Abseits der Überlegungen, an denen ihr gerade "dran" seid:
Sind die "Laufwerke" (Devices), die du für qemu-Aktionen brauchst, fest im Rechner verbaut und/oder Wechsellaufwerke?
Sind diese Devices unabhängig vom Linux-Rootdevice bzw. sonstigen Partitionen, die für dein Linux-System genutzt werden?
Was ist das "Blöde an der disk-Gruppe, warum man diese vermeiden sollte"?
Alle Blockdevices für Festplatten gehören per default eben root:disk. Dein qemu-User benötigt z.B. eigentlich "nur" rw-Zugriff auf /dev/sdb und /dev/sdd1.
Diesen User nun in disk reinzupacken ermöglicht zum einen - wie gewollt - den direkten - raw - Zugriff auf eben sdb und sdd1.
Aber ebenso den Zugriff auf alle anderen Platten/Partitionen (Systemplatte, $HOMES, etc.) - obwohl dieser Zugriff garnicht erforderlich wäre für die qemu-Aufgabenstellung.
Spätestens jetzt sollten beim Admin die Alarmglocken läuten: Eine Aufgabenstellung zu lösen, indem die notwendige Aktion dem User mehr "Rechte" gibt als dafür eigentlich notwendig ist i.d.R. "falsch gelöst".
Ich glaube dir, daß Du bisher mit disk "verantwortlich" umgegangen bist, und eben nichts "Dummes", "Willkürliches" mit *Deinem" Rechner angestellt hast. Aber Fehler z.B. passieren jedem: Ein auf das falsche Device angesetzte dd oder fdisk oder qemu, und schon wäre z.B. dein System-Device /dev/sda "hinüber" obwohl du eigentlich auf /dev/sdb agieren wolltest. Als Mitglied in der Gruppe disk könnte das deinem User "ohne Nachfrage" passieren. Ideal wäre doch ein Mechanismus, der deinen User diese "Fehler" *nur* auf ausgewählten Devices machen ließe...
Ebenso kann man sich so einem Problem "nähern" wenn man sich mal fragt: Was, wenn ich Admin an einem "Fremdrechner" wäre und müßte für "User Müller" die Aufgabenstellung lösen? Würde ich Müller in die disk-Gruppe stecken? Wäre ja fast schon ein Kündigungsgrund für mich als Admin ;-)
Gibt es also andere Möglichkeiten, um dem User (dir also) die Aufgabe zu ermöglichen, ohne dem User mehr Rechte einzuräumen als er wirklich braucht?
IMHO ja, ähnlich zur ursprünglichen Frage setuid-Bit vs. sudo.
Mittels sudo konntest du *deinem* User Root-Rechte für dedizierte Aufgaben erteilen, während ein setuid eben für Hinz und Kunz gegolten hätte. Ebenso hast du diese Root-Rechte deinem User *gezielt* nur für bestimmte Programme erteilt - und eben *nicht* den User "bequemerweise" in die wheel-Gruppe gepackt, wo er *alle* Aktionen mit Root-Rechten hätte ausführen können. Sudo "richtig und überlegt" eingesetzt hat also hier IMHO für mehr Sicherheit gesorgt als die erste Idee.
Zur qemu-Aufgabenstellung fielen mir noch zwei Ansätze ein, um z.B. die "globale disk-Gruppenorgie"<g> zu umgehen:
a) Posix ACLs
b) mit (anderen) Gruppen arbeiten
Vorausgesetzt, dein User bräuchte zum Arbeiten mit qemu wirklich nur (raw)-Zugriff auf /dev/sdb und /dev/sdd1. Nur auf diese Platte(sdb) und diese Partition(sdd1) müßte dein User direkten rw-Zugriff haben. Und eben nicht auch auf alle anderen Devices (sda mit dem System z.B.).
Möglichkeit mittels a) ACLs:
ACLs ermöglichen weitere Rechtevergaben an "Dateien" abseits der Unix-"User/Gruppen"-Rechtevergabe. So ist es z.B. möglich daß /dev/sdb weiterhin root:disk gehört mit rw-rw---- und das der User foo auch ein rw- Recht an /dev/sdb bekommt. Zu ACLs siehe z.B. man acl und:
https://wiki.archlinux.org/title/Access_Control_Lists
Für /dev/sdb würde das z.B. bedeuten:
# getfacl /dev/sdb
# file: dev/sdb
# owner: root
# group: disk
user::rw-
group::rw-
other::---
Das widerspiegelt die *normalen" Unix-Berechtigungen root:disk rw-rw---- für /dev/sdb. Weiter ACLs sind nicht gesetzt.
Jetzt gewähren wir gezielt dem User foo zusätzliche Rechte:
# setfacl -m u:foo:rw /dev/sdb
# getfacl /dev/sdb
# file: dev/sdb
# owner: root
# group: disk
user::rw-
user:foo:rw-
group::---
mask::rw-
other::---
Auf /dev/sdb haben nun weiterhin root und Mitglieder in disk rw-Zugriff, aber auch der User foo. foo erhält dadurch aber nur die wirklichen notwendigen Rechte für bestimmte Devices, nicht unnötigerweise für alle.
ACLs bleiben im Normalfall im Dateisystem gespeichert wenn einmal gesetzt. Da /dev ja ein volatiles Dateisystem ist, wird nichts "gespeichert" sondern bei einem Reboot mit Default-Werten reinitialisiert. Deshalb müßten die ACLs bei jedem Systemstart entsprechend gesetzt werden. Der momentan beste Weg sind systemd-tmpfiles.
Dazu würde z.B. eine Konfiguration in /etc/tmpfiles.d/qemu-disk-device-acls.conf angelegt:
# Gewährt dem User foo rw-Rechte an Devices für qemu-Zugriffe
#
a+ /dev/sdb - - - - u:foo:rw
a+ /dev/sdd1 - - - - u:foo:rw
Diese Konfiguration wird von systemd nun bei jedem Systemstart entsprechend gesetzt.
Möglichkeit mittels b) andere Gruppen:
//Edit: Mir fehlt aktuell die Zeit, daß näher auszuführen, ich hole das nach. Nur soviel mein Gedanke:
Man würde beim Beispiel /dev/sdb und /dev/sdd1 gezielt eben diese Devices eine andere Gruppe als disk geben. Z.B. die benannte Usergruppe des Users (root:foo z.B.), oder eine neu Gruppe. So könnte foo gezielt über die normalen Unix-Rechte den nötigen rw-Zugriff erhalten, gleichzeitig wäre verhindert daß dieser auch auf unnötige Devices ebenfalls Zugriff hätte, diese würden root:disk bleiben.
Soweit meine Gedanken...