|
|
| Zeile 34: |
Zeile 34: |
| | | | |
| | 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. | | 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 als '''dialout''' erscheint, dann reicht der Aufruf von <code>usermod</code>, so wie dargestellt. Aber <u>wichtig</u>: nach dem Aufruf von <code>usermod</code> '''ausloggen''' und '''wieder einloggen'''. |
| | + | |
| | + | Die veränderte Gruppenzugehörigkeit wird erst nach dem nächsten Einloggen wirksam. Der Aufruf von <code>usermod</code> war nicht überflüssig, denn diese Änderung ist persistent -- der User gehört dann zu der Gruppe so lange, bis man es mit <code>usermod</code> o.ä. wieder rückgängig macht. |
| | + | |
| | + | Mit Aufruf von <code>groups</code> kann man die Gruppenzugehörigkeit prüfen: |
| | + | |
| | + | <pre> |
| | + | # 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 |
| | + | </pre> |
| | + | |
| | + | ---- |
| | + | ---- |
| | + | |
| | + | |
| | + | Der Aufruf von <code>chmod</code> mit den Rechten 777 <u>ist</u> aber überflüssig, wie mittlerweile aufgefallen, und ist '''dringend nicht zu empfehlen'''. |
| | + | |
| | + | In der Ausgabe von <code>ls -l /dev/ttyACM0</code> 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. |
Version vom 15. Dezember 2023, 16:33 Uhr
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 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.