Talk:Micropython Kurs 2023

Tips für Linuxuser

Es ist nicht gesichert, daß es genau /dev/ttyACM0 ist (spezifisch mit der Zahl 0), das als serielle Schnittstelle für den Pico erscheint. Es kommt drauf an, ob und wieviele andere serielle Schnittstellen bereits da sind, und das müssen nicht unbedingt externe Geräte sein. Es ist zB gar nicht ungewöhnlich, daß das Betriebssystem ab der Bootzeit eine Systemconsole als ACM0 zur Verfügung stellt. Ein neu hinzugefügtes Gerät mit serieller Schnittstelle (wie ein eingesteckter Pico) bekommt dann die nächst höhere Zahl, zB als /dev/ttyACM1, oder noch höher, je nachdem.

Leider ist es unter Linux nicht unbedingt einfach zu bestimmen, welches Gerät unter welchem Namen unter /dev erscheint. Eine Möglichkeit wäre, dmesg aufzurufen:

# Nach dem Einstecken des Picos aufrufen
# Für dmesg ist sudo meistens erforderlich
$ sudo dmesg
[...]
[944704.804798] usb 1-1.1.3.3: new full-speed USB device number 82 using xhci_hcd
[944704.922582] usb 1-1.1.3.3: New USB device found, idVendor=2e8a, idProduct=000a, bcdDevice= 1.00
[944704.922603] usb 1-1.1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[944704.922610] usb 1-1.1.3.3: Product: Pico
[944704.922616] usb 1-1.1.3.3: Manufacturer: Raspberry Pi
[944704.922622] usb 1-1.1.3.3: SerialNumber: DF6018F2676E5438
[944704.935735] cdc_acm 1-1.1.3.3:1.0: ttyACM0: USB ACM device
[...]

Da sieht man ttyACM0 in der letzten Zeile.

Oder:

• ls /dev/ttyACM* aufrufen
• Pico einstecken
• Nochmal ls /dev/ttyACM*

Der Pico ist dann derjenige, der im zweiten Aufruf neu hinzugekommen ist.

Der Satz "Unter Linux erscheint der Pico unter /dev/ttyACM*" ist eine Zusammenfassung mit einigen stillschweigenden Annahmen -- das gilt nicht für jeden Pico in jedem Zusammenhang. Aber ich vermute, daß es immer gilt, wenn Micropython auf dem Pico geladen ist, also kann das aus meiner Sicht so stehen.

Daß die dev-Datei für die serielle Schnittstelle immer der Gruppe dialout zugeordnet wird, ist ein wenig gewagter. Die gängigen Distros sind so konfiguriert, also werden viele es so sehen. Aber das bestimmt das Betriebssystem -- der Pico kann es nicht beeinflußen, und die Konfig könnte anders sein. Mich würde zB nicht überraschen, wenn jemand sowohl Owner als auch Group als root sieht.

Wenn die Gruppe nicht als dialout erscheint, kann man mit udev-Regeln die System-Konfig so anpassen -- damit kann man sowohl die Gruppe als auch die Zugriffs-Bits automatisch einstellen.

Ich würde hier nicht auf das Thema eingehen wollen, denn vermutlich wird das kein Problem für Kurs-Teilnehmer. Für alle Fälle hier ein Link darüber:

https://wiki.archlinux.org/title/udev#Allowing_regular_users_to_use_devices

Für den Pico gilt hier: idVendor=2e8a und idProduct=000a, wie man oben in der Ausgabe von dmesg sieht.

Wenn die Gruppe als dialout erscheint, dann reicht der Aufruf von usermod, so wie dargestellt. Aber wichtig: nach dem Aufruf von usermod ausloggen und wieder einloggen.

Die veränderte Gruppenzugehörigkeit wird erst nach dem nächsten Einloggen wirksam. Der Aufruf von usermod war nicht überflüssig, denn diese Änderung ist persistent -- der User gehört dann zu der Gruppe so lange, bis man es mit usermod o.ä. wieder rückgängig macht.

Mit Aufruf von groups kann man die Gruppenzugehörigkeit prüfen:

# So sieht es bei mir aus. dialout ist dabei.
$ groups
geoff dialout cdrom floppy audio dip video plugdev netdev bluetooth lpadmin scanner wireshark varnish docker

Der Aufruf von chmod mit den Rechten 777 ist aber überflüssig, wie mittlerweile aufgefallen, und ist dringend nicht zu empfehlen.

In der Ausgabe von ls -l /dev/ttyACM0 kann man Lese- und Schreibrechte für Owner und Group sehen ('r' und 'w' Bits für Owner und Group). Das ist vollkommen ausreichend für einen Benutzer, der zur Gruppe gehört.

Mit 777 wird zum einen das Executable-Bit auch eingeschaltet, und das braucht man hier nicht. Die dev-Datei als Abstratktion für die serielle Schnittstelle ist kein Programm.

Und zum anderen, viel bedenklicher: Mit 777 werden auch alle Zugriffsbits für "World" gesetzt, womit der Zugriff beliebig offen wird. Damit wird der gesamte Sinn und die Sicherheit von Zugriffsrechten unterminiert.

Der Rückgriff auf 777 ist verlockend, wenn es einmal schwierig wird, und man könnte zum Gedanken verleitet werden, "für den Pico ist das doch nicht so schlimm". Aber das ist schelchte Sicherheitspraxis, immer und ausnahmslos schlimm, und muß verlernt werden. Wenn es ein Zugriffsproblem gibt, dann das Problem verstehen und richtig lösen, in keinem Fall mit 777.

In unserem Workshop wollen wir den Teilnehmern keine schlechte Sicherheitspraxis nahelegen, auch nicht ein kleines bißchen. Schließlich sind wir der Attraktor, doch nicht irgendwer.