Ich bin es gewohnt, daß Avrdude für USBasp und AVRISPmkII udev Regeln benötigt, damit man es ohne Sudo benutzen kann.
Das ist aber wohl nicht mehr nötig, zumindest in Debian. Weiß jemand, warum das so ist oder wo ich Infos dazu finden kann?
Möglicherweise werden die Devicefiles per default mit einer Gruppe erstellt, in welcher dein User ist.
Schau doch mal, was die Devices als Berechtigung haben. Vielleicht hat ja jemand die udev-Regeln für die Atmel-Tools bereits in die reguläre distribution mit aufgenommen?
Die Device gehören root.root mit Permissions 0660. Ich bin weder root noch in der Gruppe root.
Meine Versuche, davon (mit cat Befehl) zu lesen wurden verweigert. Avrdude funktioniert aber trotzdem.
Wenn ich die gewohnten udev Rules anlege, dann haben die Device 0666 (so steht das in den Rules). Ich habe mir also ganz sicher die richtigen Device angeschaut.
:
Bearbeitet durch User
Hat dir jemand AVRDUDE setuid root installiert?
Für ein AVRISPmkII habe ich jedenfalls keine wirkliche Erklärung, denn der Code greift auf das Device zu, nicht irgendwie auf eine Abstraktionsschicht darüber (wie bei den HID-basierten Teilen).
Du könntest natürlich auch mal ein strace drüber schicken.
Hat dir jemand AVRDUDE setuid root installiert?
Wäre jetzt auch mein Frage gewesen. Diese Unsitte hält leider immer mehr Einzug. Installiert man z.B. VSCode als Debian Packet via den offiziellen Microsoft apt repositories, dann bekommt man auch so ein setuid root Programm untergeschoben, ich vermute mal um den Updater starten zu können.
via den offiziellen Microsoft apt repositories, dann bekommt man auch so ein setuid root Programm untergeschoben
Das ist jetzt nicht wirklich verblüffend, da es von den offiziellen eisernen Verfechtern von höchster Computersicherheit im Allgemeinen und bester Privatsphäre im Speziellen kommt.
Schau doch mal, was die Devices als Berechtigung haben. Vielleicht hat ja jemand die udev-Regeln für die Atmel-Tools bereits in die reguläre distribution mit aufgenommen?
Seit Bullseye oder noch länger liefert das Paket avrdude udev-Regeln für über 50 Geräte mit. Die Datei ist heute immer noch die gleiche (aber bei udev weiß man ja nie...).
Die Device gehören root.root mit Permissions 0660. Ich bin weder root noch in der Gruppe root.
Meine /dev/ttyUSB* gehören root:dialout; ohne avrdude und auf ziemlich originalem Debian Bookworm und Forky.
Danke für eure Anregungen. Genau solche Antworten hatte ich mir erhofft.
Mein Avrdude hat kein suid Bit.
Mir ist ein kleines Detail aufgefallen:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Die unteren beiden sind Programmieradapter. Das "+" hat hier offenbar etwas zu bedeuten (erweiterte Zugriffsrechte?). Von einer udev Regel kommt das aber nicht. Woher könnte es sonst kommen?
Seit Bullseye oder noch länger liefert das Paket avrdude udev-Regeln für über 50 Geräte mit.
Das wird es wohl sein. Ich habe gerade mal avrdude deinstalliert. Jetzt ist das + weg und wenn ich jetzt eine andere Binary von avrdude aufrufe kommt die erwartete Fehlermeldung
Warning: cannot open USB device: Permission denied
Dann schaue ich mal nach, wo diese 50 Rules liegen...
:
Bearbeitet durch User
Das "+" hat hier offenbar etwas zu bedeuten (erweiterte Zugriffsrechte?).
Genau, ACLs. Lass mal getfacl auf die Devices los.
Das "+" hat hier offenbar etwas zu bedeuten (erweiterte Zugriffsrechte?).
Sozusagen, das zeigt eine vorhandene Linux-ACL an.
Woher könnte es sonst kommen?
https://superuser.com/questions/989662/how-is-the-acl-set-on-usb-devices/989721#989721
Debians avrdude Paket enthält die Datei /usr/lib/udev/rules.d/60-avrdude.rules
Ich wusste nicht, dass udev Rules auch dort liegen können. Mal wieder was dazu gelernt.
Debians avrdude Paket enthält die Datei /usr/lib/udev/rules.d/60-avrdude.rules
Und die setzt ACLs, statt auf Basis von Gruppenrechten zu arbeiten? Cool.
Ich wusste nicht, dass udev Rules auch dort liegen können. Mal wieder was dazu gelernt.
Und die setzt ACLs, statt auf Basis von Gruppenrechten zu arbeiten? Cool.
Macht sie schon seit Ewigkeiten:
1 |
|
2 |
|
Hier in OldOldStable Debian 11:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
:
Bearbeitet durch User
94-SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2fff", TAG+="uaccess"
Und wie löst dieser TAG jetzt in ACLs auf? Da werde ich aus der man page nicht schlau. Die erzählt irgendwas, dass der tag für irgendwelche Filter gut sei.
Einen direkten Aufruf von setfacl sehe ich wiederum nur in /lib/udev/rules.d/99-libsane1.rules
Und wie löst dieser TAG jetzt in ACLs auf?
Ich meine, dass der systemd login daemon dies auflöst und die Rechte dynamisch vergibt. Aber nagel' mich nicht drauf fest.
Norbert schrieb:
94-SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2fff", TAG+="uaccess"
Und wie löst dieser TAG jetzt in ACLs auf? Da werde ich aus der man page nicht schlau. Die erzählt irgendwas, dass der tag für irgendwelche Filter gut sei. Einen direkten Aufruf von setfacl sehe ich wiederum nur in /lib/udev/rules.d/99-libsane1.rules
"The key of the rule is the attached TAG named uaccess, which has the effect that the login daemon applies a dynamic user access control list to the device node making the device usable for the currently logged-in user." https://avrdudes.github.io/avrdude/8.1/avrdude_34.html
KI Search Assist: "Understanding the TAG+="uaccess" in Udev Rules Purpose of TAG+="uaccess"
The TAG+="uaccess" directive in udev rules is used to grant access to devices for logged-in users. This is achieved through dynamic Access Control Lists (ACLs) that are managed by systemd-logind. When this tag is applied, it allows users to interact with devices without needing to be part of specific groups."
Ich meine, dass der systemd login daemon dies auflöst und die Rechte dynamisch vergibt.
So ähnlich, udev kümmert sich darum, holt sich die Informationen über den lokalen User aber vom logind.
https://github.com/systemd/systemd/blob/main/src/udev/udev-builtin-uaccess.c
Gab es auch schon ohne systemd (udev-acl), siehe der oben verlinkte superuser.com-Thread.
So ähnlich, udev kümmert sich darum, holt sich die Informationen über den lokalen User aber vom logind.
Ah, genau, so herum.
Der TAG=='uaccess' in der udev-rule veranlasst ein Nachfragen beim systemd-login-daemon.
Der TAG=='uaccess' in der udev-rule veranlasst ein Nachfragen beim systemd-login-daemon.
Dann habe ich zumindest die Dokumentation dieses Features nicht in der man page gefunden.
Norbert schrieb:
Der TAG=='uaccess' in der udev-rule veranlasst ein Nachfragen beim systemd-login-daemon.
Dann habe ich zumindest die Dokumentation dieses Features nicht in der man page gefunden.
Die systemd Dokumentation ist in großen Teilen milde formuliert grottenschlecht. Wissen sie auch selbst: https://github.com/systemd/systemd/issues/4288
Hier der Part:
We should also document the replacement mechansim based on uacess/udev/logind. How those pieces fit together, like tagging the devices via udev rules, logind applying the permissions for local and active users etc.
"An undocumented feature is called a bug." (Autor unbekannt)
Ich denke das ist eine gute Gelegenheit, hier etwas historischen Kontext zu schaffen, im Bezug zu dem uaccess Zeugs.
Ursprünglich hat man für die meisten Geräte einfach die Gruppe gesetzt, in der die User waren, die Zugriff darauf brauchten. Mit den Mechanismus kann jeder Prozess mit der passenden Supplementary Group grundsätzlich das Device jederzeit öffnen, und wenn es das Device erlaubt, können das auch mehrere Prozesse von unterschiedlichen Usern gleichzeitig tun, genau so wie das auch bei normalen Files funktioniert.
Bei gewissen Geräten will man das aber womöglich nicht, das ist wo die Idee des Seats aufkam; wenn man an einem PC sitzt, hat man Tastatur, Maus (Eingabegeräte), Bildschirme, und Lautsprecher vor sich. Man meldet sich an, und der dort sitzende Benutzer / dessen Programme, sollen dann die Kontrolle über die sich dort befindenden Geräte bekommen. Andere Programme von anderen Nutzern, die z.B. über SSH oder so angemeldet sind, sollen nicht deine Tastatureingaben mitlesen oder plötzlich was auf den Lautsprechern abspielen oder dir den Bildschirm wegnehmen.
Bei VTs, also der Linux Konsole, gibt es historisch bereits einen Mechanismus, das zumindest für TTYs und deren Input / Output zu regeln. Der Kernel regelt intern, welcher VT angezeigt wird somit welcher TTY aktiv ist, und welcher den Input bekommt. Zudem gibt es von Unix her noch recht komplexe Logik mit Prozessgruppen und Controlling Terminals, die ähnliches bei mehreren Anwendungen auf einem Terminal regeln.
Bei der Einführung des DRM/KMS Grafiksubsystems über die Display Server wie z.B. Xorg Sachen auf den Bildschirmen ausgeben, hat man sich den Mechanismus ausgedacht, dass der erste, der als Root die DRM Card Node öffnet, KMS Master werden kann, das heisst, er kann die Outputs / Bildschirme an der Grafikkart4e konfigurieren und was darauf anzeigen. KMS Master kann nur einer werden, wobei das aber eine Eigenschaft der Filedescription des Filedescriptors ist, den man beim Öffnen der Datei bekommt, und den kann man auch an andere Prozesse weitergeben.
Bei einem Switch zwischen VTs mussten die Programme damals kooperieren, XOrg musste seine KMS Master Berechtigung aufgeben, und das Programm auf dem Neuen VT hat die dann mit drmSetMaster wieder genommen, was etwas Fehleranfällig sein konnte.
Logind hört man oft im Bezug auf Seat Management, aber vor Logind kahm erstmal Consolekit. Von da kommt auch, was heute die uaccess Geschichte ist. Beim Login wird bei den Devicefiles, die der Benutzer braucht, ein ACL hinzugefügt, so dass dieser darauf zugreifen kann. Damit sollte die Problematik mit den Seats gelöst werden. Aber bei Unix Systemen, insbesondere Linux, finden Berechtigungsprüfungen nur beim Öffnen der Datei statt, sobald man den File Deskriptor hat, hat man automatisch auch die Berechtigung, darauf zuzugreifen, und man kann einem diesen nicht mehr weg nehmen.
Dann kahm dann Logind ins Spiel. Logind übernimmt den VT Switching part, es öffnet die DRI Card Nodes, setzt und dropt den KMS Master Status, und übergibt den File Deskriptor dem Grafikserver (per DBUS). Da logind nun den KMS Master zustand Droppen kann, ist man nicht mehr auf die Kooperation der Grafikserver angewiesen. Bei Input Devices gibt es ebenfalls einen Mechanismus, mit dem Logind verhindert, dass Prozesse, die dies nicht sollten, Input events bekommen.
logind, Xorg, und DRM wurden damals von den selben Personen kontrolliert. Logind wurde beworben als notwendig, weil es sicherer als Cnsolekit sei. Aber nach wie vor gibt es keinen allgemeingültigen Mechanismus, um einen File Deskriptor zurückzuziehen, sie haben das Problem nur beim DRM Subsystem "gelöst", der Rest ist nicht besser geworden. Auch Logind setzt noch die ACLs, und bei Geräten wie TTYs, DVD Brennern, etc. kann Programmen, die diese bereits geöffnet haben, der Zugriff nicht mehr entzogen werden. Der "uaccess" mechanismus, der die ACLs auf den Device Files setzt, und Programme auf diese zugreifen lässt, kann aber auf alle Arten von Device Files Gleichermassen angewendet werden. Nur beim Wegnehmen des Zugriffs gibt es keine einheitliche Lösung.
Deshalb bevorzuge ich, mit wenigen Ausnahmen, einfach bei den Device Files die Gruppe zu setzen und den Usern hinzuzufügen, statt dem uaccess Mechanismus zu nutzen, da hat man keinen falschen Sinn der Sicherheit, und es ist einem auch nicht im Weg.
Jedenfalls, dass ist wie das ganze zustande gekommen ist.
PS: Noch eine kleine witzige Sache nebenbei, für die VR Headsets wurden mal noch DRM Leases eingeführt, damit kann man für einzelne Outputs einen FD erstellen (statt auf die ganze DRM Card Node mit allen Outputs zugriff haben zu müssen), einer Anwendung übergeben, diese kontrolliert den Output dann vollständig, ist quasi dessen KMS Master. Eigentlich Ideal für Seat Management, insbesondere für Multiseat und Container, aber keiner hat es je dafür verwendet.
[...]
Jedenfalls, dass ist wie das ganze zustande gekommen ist.
Vielen Dank für diese Darstellung der Historie. Das war für mich persönlich das bei weitem nützlichste Posting in µc.net-Forum seit langer Zeit. Das hat viel vorhandenes Detailwissen in einen größeren Zusammenhang gebracht.