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)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.