Rohes Bild sicher auf USB-Sticks schreiben


7

Beim Versuch, viele verschiedene Linux-Distributionen auf allen Arten von Hardware zu verwenden, tippe ich häufig folgende Befehle ein:

sudo dd if=xubuntu-13.10-desktop-amd64.iso of=/dev/sdc bs=10240

Unnötig zu erwähnen, dass ich früher oder später das Ziel falsch eingeben und eine Festplatte anstelle des vorgesehenen USB-Laufwerks löschen werde. Ich möchte hier nicht sudojedes Mal verwenden.

Auf meinem System, einem ziemlich modernen Ubuntu, /dev/sdclauten die Berechtigungen für : (wenn ein Stick vorhanden ist):

$ ls -al /dev/sdc*
brw-rw---- 1 root disk 8, 32 Apr  6 22:10 /dev/sdc

Wie erteile ich meinem normalen Benutzer Schreibzugriff auf zufällige USB-Sticks, jedoch nicht auf andere in meinem System vorhandene Festplatten?

Antworten:


11

Ich denke, Sie können UDEV verwenden, um das zu tun, was Sie wollen. Erstellen Sie eine Regeldatei, indem /etc/udev/rules.d/99-thumbdrives.rulesSie einfach eine Regel hinzufügen, die entweder einer Unix-Gruppe oder dem Benutzer den Zugriff auf beliebige USB-Sticks ermöglicht.

KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", OWNER="<user>", GROUP="<group>", MODE="0660"

Würde das Gerät mit dem Benutzer <user>und der Gruppe erstellen <group>.

Beispiel

  1. Nach dem Hinzufügen dieser Zeile zu meinem System.

    KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", OWNER="saml", GROUP="saml", MODE="0660"
    
  2. Und meine Regeln neu laden:

    $ sudo udevadm control --reload-rules
    
  3. Wenn ich jetzt einen Thumbdrive in mein System einfüge, wird mein /var/log/messageswie folgt angezeigt :

    $ sudo tail -f /var/log/messages
    Apr 13 11:48:45 greeneggs udisksd[2249]: Mounted /dev/sdb1 at /run/media/saml/HOLA on behalf of uid 1000
    Apr 13 11:51:18 greeneggs udisksd[2249]: Cleaning up mount point /run/media/saml/HOLA (device 8:17 is not mounted)
    Apr 13 11:51:18 greeneggs udisksd[2249]: Unmounted /dev/sdb1 on behalf of uid 1000
    Apr 13 11:51:18 greeneggs kernel: [171038.843969] sdb: detected capacity change from 32768000 to 0
    Apr 13 11:51:39 greeneggs kernel: [171058.964358] usb 2-1.2: USB disconnect, device number 15
    Apr 13 11:51:46 greeneggs kernel: [171066.053922] usb 2-1.2: new full-speed USB device number 16 using ehci-pci
    Apr 13 11:51:46 greeneggs kernel: [171066.134401] usb 2-1.2: New USB device found, idVendor=058f, idProduct=9380
    Apr 13 11:51:46 greeneggs kernel: [171066.134407] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    Apr 13 11:51:46 greeneggs kernel: [171066.134410] usb 2-1.2: Product: USBDrive
    Apr 13 11:51:46 greeneggs kernel: [171066.134412] usb 2-1.2: Manufacturer: JMTek
    Apr 13 11:51:46 greeneggs kernel: [171066.135470] usb-storage 2-1.2:1.0: USB Mass Storage device detected
    Apr 13 11:51:46 greeneggs kernel: [171066.136121] scsi17 : usb-storage 2-1.2:1.0
    Apr 13 11:51:46 greeneggs mtp-probe: checking bus 2, device 16: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
    Apr 13 11:51:46 greeneggs mtp-probe: bus: 2, device: 16 was not an MTP device
    Apr 13 11:51:47 greeneggs kernel: [171067.139462] scsi 17:0:0:0: Direct-Access     JMTek    USBDrive         7.77 PQ: 0 ANSI: 2
    Apr 13 11:51:47 greeneggs kernel: [171067.140251] sd 17:0:0:0: Attached scsi generic sg2 type 0
    Apr 13 11:51:47 greeneggs kernel: [171067.142105] sd 17:0:0:0: [sdb] 64000 512-byte logical blocks: (32.7 MB/31.2 MiB)
    Apr 13 11:51:47 greeneggs kernel: [171067.144236] sd 17:0:0:0: [sdb] Write Protect is off
    Apr 13 11:51:47 greeneggs kernel: [171067.145988] sd 17:0:0:0: [sdb] No Caching mode page found
    Apr 13 11:51:47 greeneggs kernel: [171067.145998] sd 17:0:0:0: [sdb] Assuming drive cache: write through
    Apr 13 11:51:47 greeneggs kernel: [171067.153721] sd 17:0:0:0: [sdb] No Caching mode page found
    Apr 13 11:51:47 greeneggs kernel: [171067.153728] sd 17:0:0:0: [sdb] Assuming drive cache: write through
    Apr 13 11:51:47 greeneggs kernel: [171067.159028]  sdb: sdb1
    Apr 13 11:51:47 greeneggs kernel: [171067.164760] sd 17:0:0:0: [sdb] No Caching mode page found
    Apr 13 11:51:47 greeneggs kernel: [171067.164768] sd 17:0:0:0: [sdb] Assuming drive cache: write through
    Apr 13 11:51:47 greeneggs kernel: [171067.164775] sd 17:0:0:0: [sdb] Attached SCSI removable disk
    Apr 13 11:51:47 greeneggs kernel: [171067.635474] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
    Apr 13 11:51:47 greeneggs udisksd[2249]: Mounted /dev/sdb1 at /run/media/saml/HOLA on behalf of uid 1000
    
  4. Das Auschecken der Gerätedateien unter /devzeigt nun Folgendes:

    $ ls -l /dev/sd*
    brw-rw----. 1 root disk 8,  0 Apr 13 09:17 /dev/sda
    brw-rw----. 1 root disk 8,  1 Apr 13 09:17 /dev/sda1
    brw-rw----. 1 root disk 8,  2 Apr 13 09:17 /dev/sda2
    brw-rw----. 1 saml saml 8, 16 Apr 13 11:51 /dev/sdb
    brw-rw----. 1 root disk 8, 17 Apr 13 11:51 /dev/sdb1
    

Es scheint also funktioniert zu haben.

Expliziter sein

Das Obige wird funktionieren, aber wahrscheinlich werden diese Regeln auf jedes Blockgerät angewendet, was nicht ganz das ist, was wir wollen. Um den Fokus etwas ATTRS{..}==...einzuschränken, können Sie Attributregeln verwenden, um die Anwendung auf bestimmte Hardware zu beschränken. In meinem Fall möchte ich, dass es nur auf einen einzelnen USB-Stick angewendet wird.

Schritt 1 - Gerät mit eindeutiger ID

Zu Beginn können wir diesen Befehl verwenden, sobald wir den bestimmten USB-Stick bereitgestellt haben, damit wir ihn udevadmüberprüfen und nach seinen bestimmten Attributen suchen können.

Hier konzentriere ich mich auf die Attribute "Hersteller" und "Produkt".

$ udevadm info -a -p $(udevadm info -q path -n /dev/sdb)|grep -iE "manufacturer|product"
    ATTRS{manufacturer}=="JMTek"
    ATTRS{idProduct}=="9380"
    ATTRS{product}=="USBDrive"
    ATTRS{idProduct}=="0020"
    ATTRS{manufacturer}=="Linux 3.13.7-100.fc19.x86_64 ehci_hcd"
    ATTRS{idProduct}=="0002"
    ATTRS{product}=="EHCI Host Controller"

ANMERKUNG: ATTRS{..}==.. Attribute sind Attribute für übergeordnete Geräte in der Hierarchie, von der die Gerätedatei dieses Geräts letztendlich stammt. In unserem Fall stammt das hinzugefügte Blockgerät /dev/sdbvon einem übergeordneten USB-Gerät. Daher suchen wir beispielsweise nach den Attributen dieses übergeordneten Geräts ATTRS{manufacturer}=....

In diesem Beispiel wähle ich den Hersteller "JMTek" und das Produkt "USBDrive" aus.

Schritt 2 - Ändern Sie .rules flie

Fügen wir diese zusätzlichen Bits unserer Originaldatei hinzu .rules.

KERNEL=="sd*", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", ATTRS{manufacturer}=="JMTek", ATTRS{product}=="USBDrive", OWNER="saml", GROUP="saml", MODE="0660"

Schritt 3 - Probieren Sie es aus

Wenn wir nun unsere Regeln neu laden und unseren USB-Stick wieder aushängen / entfernen / wieder einstecken, erhalten wir diese Regel:

$ ls -l /dev/sdb*
brw-rw----. 1 saml saml 8, 16 Apr 13 12:29 /dev/sdb
brw-rw----. 1 root disk 8, 17 Apr 13 12:29 /dev/sdb1

Wenn ich jedoch ein völlig anderes Gerät einfüge:

$ ls -l /dev/sdb*
brw-rw----. 1 root disk 8, 16 Apr 13 12:41 /dev/sdb
brw-rw----. 1 root disk 8, 17 Apr 13 12:41 /dev/sdb1

Verweise


Dies ist bereits die richtigste Antwort. Sie enttäuschen nicht oft, slm.
Mikeserv

Sollten Sie nicht das Block-Subsystem verwenden? Wenn ich mich nicht irre, stimmt diese Regel mit dem Gerät / dev / usb / xxx / yyy anstelle von / dev / sdc überein. ATTRS anstelle von ATTR sollte mit übergeordneten Geräten (dh Block) übereinstimmen.
Lekensteyn

@Lekensteyn - danke, es hat ursprünglich bei mir nicht ganz funktioniert und ich konnte nicht herausfinden warum. Mit Ihrem großen Hinweis und dem Verschieben der Regel zum Ende ( 99-...) kann ich jetzt tatsächlich eine echte Demo zeigen, die funktioniert. Nochmals vielen Dank für die Anleitung!
slm

Ich musste ein wenig kämpfen, aber am Ende benutzte ich das, SUBSYSTEM=="block", ENV{ID_BUS}=="usb", GROUP="mogul"was ich als "jedes USB-Laufwerk wird im Gruppenmogul sein" las. Die Verwendung einer 99-Regel hat auch geholfen
Mogul

@mogul - ja, es ist ein bisschen Versuch und Irrtum, die Dinge
slm
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.