Grundlegendes zur Mount-Option nodev und ihrer Verwendung mit USB-Flash-Laufwerken


10

mount (8) OS X-Handbuchseite beschreibt die nodevOption:

Interpretieren Sie keine Zeichen und blockieren Sie keine speziellen Geräte im Dateisystem. Diese Option ist nützlich für einen Server mit Dateisystemen, die spezielle Geräte für andere als eigene Architekturen enthalten.

Das allein verstehe ich nicht ganz ... 

… Für mich ist der wichtigere Teil dieser Frage - der mir helfen kann, die Option zu verstehen -:

Warum werden USB-Sticks mit der Option nodev gemountet?

Beispiel:

sh-3.2$ mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s2 on /Volumes/swap (hfs, local, journaled)
/dev/disk0s4 on /Volumes/spare (hfs, local, journaled)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
localhost:/Eiu9XWYlwq4E8x9l_bQTiX on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)
/dev/disk3 on /Volumes/gjp22 (zfs, local, journaled, noatime)
/dev/disk3s1 on /opt (zfs, local, journaled, noatime)
/dev/disk6 on /Volumes/zhandy (zfs, local, journaled, noatime)
/dev/disk8s1 on /Volumes/experiment (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk10 on /Volumes/tall (zfs, local, journaled, noatime)
/dev/disk11s2 on /Volumes/LaCie Little Big Disk (hfs, local, nodev, nosuid, journaled, noowners)
/dev/disk12 on /Volumes/twoz (zfs, local, journaled, noatime)
Wuala on /Volumes/WualaDrive (osxfusefs, local, nodev, nosuid, synchronous, mounted by gjp22)
/dev/disk14s2 on /Volumes/Time Machine Backups (hfs, local, nodev, nosuid, journaled)

In diesem Beispiel sind die vier Bände mit nodev:

  1. Experimentieren - auf einem USB-Stick
  2. LaCie Little Big Disk - Auf einem Festplattenlaufwerk in FireWire 400 enthält dieses Volume eine Time MachineBackups.backupdb
  3. Die Integration des Wuala- Dateisystems verwendet FUSE für OS X.
  4. Time Machine Backups

Ich kann verstehen, dass 2, 3 und 4 etwas Besonderes sind. Jedoch:

  • Ich kann die Relevanz nodeveines USB-Sticks nicht verstehen .

Weitere Referenzen

USB-Festplatten automatisch mounten (wie es funktioniert) - Unix und Linux

Hintergrund

Ich möchte verstehen, warum Time Machine in Lion und Mountain Lion nicht von USB-Sticks sichern kann. Bei dieser Frage geht es jedoch allgemeiner um die nodevOption.

Antworten:


17

Die nodevOption weist das System nicht zulassen Erstellung und den Zugriff auf Geräteknoten - die Art von speziellen Dateien , die Sie haben in /dev.

Sie haben beispielsweise /dev/disk0direkten Zugriff auf alle auf der ersten Festplatte gespeicherten Daten, ohne die höheren Ebenen wie das Dateisystem oder den Code für die Berechtigungsprüfung durchlaufen zu müssen. Die einzige überprüfte Berechtigung besteht darin, ob Sie diesen bestimmten Geräteknoten öffnen dürfen zum Lesen oder Schreiben.

Dies bedeutet, dass jeder Benutzer , wenn er /dev/disk0für die Welt lesbar gemacht wurde, die Dateien anderer Benutzer auf derselben Festplatte leicht lesen kann (wenn sie nicht verschlüsselt sind), indem er einfach von liest ./dev/sda

Abhängig vom Betriebssystem gibt /deves normalerweise viele andere Arten von Geräteknoten, einschließlich des /dev/memZugriffs auf den gesamten (physischen und / oder virtuellen) Speicher des Systems - allerdings nicht bei Systemen, auf denen ein Kernel ausgeführt wird, mit dem kompiliert wurde CONFIG_STRICT_DEVMEM(außer root ).

Aus diesem Grund darf normalerweise nur root Geräteknoten erstellen (für andere Benutzer mknodwird "Operation nicht zulässig" zurückgegeben), und alle vorhandenen Geräteknoten werden an einem einzigen Speicherort ( /dev) mit strengen Dateiberechtigungen gespeichert, die normalen Benutzern keine Berechtigung geben Lese- oder Schreibzugriff. (Mit einigen Ausnahmen.) In der heutigen Zeit kann jedoch jeder die Nur-Root-Beschränkung leicht umgehen, indem er zu einem anderen Computer wechselt, auf den er bereits Root-Zugriff hat, und damit einige Geräteknoten auf einem USB-Laufwerk erstellt und sehr offene Berechtigungen festlegt. und verbinden Sie dieses Laufwerk mit Ihrem Computer.

Dies nodevverhindert die Option - selbst wenn jemand einen weltweit lesbaren / weltweit beschreibbaren Geräteknoten auf seinem eigenen Laufwerk erstellt, weigert sich das Betriebssystem aufgrund der nodevbeim Mounten verwendeten Option, etwas damit zu tun .


Die gleichen Gründe gelten für die nosuidOption, mit der das Betriebssystem angewiesen wird, das setuid- Bit zu ignorieren, das normalerweise dazu führt, dass ein Programm mit anderen Berechtigungen als die des Benutzers ausgeführt wird. Hat beispielsweise /usr/bin/sudodas setuid- Bit und gehört root, sodass es immer die gleichen Berechtigungen wie root hat.


Dies ist eine großartige Antwort - danke. Wenn ich die Dinge richtig verstehe, stellt sich im ZEVO-Supportforum eine andere Frage: Warum werden ZEVO-ZFS-Mounts ohne die Option nodev bereitgestellt? (Im Moment habe ich kein Ersatz-USB-Festplattenlaufwerk, das ich allein an HFS Plus weitergeben kann.)
Graham Perrin

@GrahamPerrin: Optionen, nodevdie standardmäßig deaktiviert sind und beim Mounten explizit festgelegt werden müssen. Der OS X-Wechseldatenträger setzt sie automatisch ein, die entsprechenden Programme unter Linux auch, aber sie werden nicht festgelegt, wenn sie mountvom Terminal ausgeführt werden, es sei denn, Sie fügen sie manuell hinzu -o nodev. (Diesmount beeinträchtigt die Sicherheit nicht, da für sich selbst Root-Rechte erforderlich sind.) Dies hängt also davon ab, wie Ihre ZEVO ZFS-Festplatte bereitgestellt wird.
Benutzer1686

Mit ZEVO Community Edition 1.1.1 ist der Import dynamisch (automatisch) und es scheint, dass die Standardeinstellung darin besteht, automatisch ohne zu mounten nodev. Weder der Import noch der ZFS-Mount erfordern eine Authentifizierung. Mal sehen, wie sich die Dinge im ZEVO-Bereich entwickeln.
Graham Perrin

@grawity: Falsch, die nodevOption weist an, Lese- und Schreibvorgänge in Gerätedateien abzulehnen, damit auch vorhandene Dateien betroffen sind. Sie können sie weiterhin erstellen.
user2284570
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.