☰

NFSv4-FSID-Option und der Zweck von Export-Roots

tag-icon • tag-icon nfs4
NFSv4-FSID-Option und der Zweck von Export-Roots

Mein Dateiserver hat nur eine große Partition, die Sachen unter /exports freigibt. Mit den alten NFSv3-Exporten hatte ich also:

/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

Daher habe ich beschlossen, zum NFSv4-Stil zu wechseln und habe es wie folgt geändert:

/exports          192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc              192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.

Ich habe dann die Mount-Befehle in exclude geändert /exports. Natürlich /etckonnte es nicht gemountet werden (obwohl es keinen Fehler gab, sondern nur gesperrt war, bis es unterbrochen wurde). Wie erwartet /exportswurden die ACLs jedoch immer noch nach unten vererbt, alle Freigaben waren schreibgeschützt und root wurde überall unterdrückt.

Ich habe auch versucht, die ACL /exports/rootauf eine einzelne Maschine zu ändern, aber es hat keinen Unterschied gemacht.

Abgesehen davon, dass man eine eindeutige Kennung für die Dateisysteme bereitstellen kann, für die eine solche Kennung nicht ermittelt werden kann, welchen Sinn hat es also, ein Exportstammverzeichnis mit folgendem zu definieren fsid=0:

  • Dadurch wird die Flexibilität hinsichtlich der Einrichtung von Freigaben eingeschränkt (d. h. das Vererbungsproblem, es sei denn, es handelt sich um unterschiedliche Dateisysteme und Sie verwenden nocrossmount?).
  • Selbst wenn Sie das NFSv3-Setup im alten Stil verwenden, können Sie es immer noch nicht mounten. /etcWelche zusätzliche Sicherheit bietet es also?

Ist das fsid=0nur sinnvoll, wenn /exportses sich lediglich um einen Einbindungsbereich für separate Dateisysteme handelt, die dort eingebunden und mit unterschiedlichen ACLs exportiert werden?

Mir scheint, dass das Setup von NFS-Servern umgedreht wurde. Früher waren unter Solaris alle gemeinsam genutzten Inhalte direkt unter gemountet /exportund freigegeben. Der Server war per /home/userBind unter gemountet /export/home/user. Aber jetzt /homeist der eigentliche Mount-Speicherort des Dateisystems und per Bind unter gemountet /exports.

Ist das richtig?

Bitte beachten Sie: Die obigen Beispiele dienen nur zur Veranschaulichung, also bitte keine Kommentare darüber, ob es klug ist, nicht zu verwenden no_squash_root, ich weiß.

Vielen Dank.

Antwort1

Es handelt sich um eine architektonische Änderung in der Funktionsweise des NFS-Mount-Protokolls.

In NFSv2/v3 gab es ein völlig separates „MOUNT“-RPC-Protokoll, das es dem Client ermöglichte, einen Dateihandle jedes exportierten Dateisystems über seinen Pfad abzurufen. Doch im nachfolgenden WebNFS – und später in NFSv4 – wurde das Mounten in eine In-Band-NFS-Operation geändert, und gleichzeitig wurde die Operation so geändert, dass sie einen einzelnen „Root“-Dateihandle zurückgab, von dem dann alle Pfadsuchen abstammen. (Tatsächlich hatte WebNFS zwei solcher Roots, ein weiterer war ein „öffentlicher“ Root für nfs://-URLs, der es nicht in NFSv4 geschafft hat.)

Damit die Operation 'PUTROOTFH' funktioniert, muss esSeiein Root-Dateisystem irgendeiner Art, da es nicht mehr möglich ist, die Schritte zu überspringen – alle Pfaddurchläufe sind eine Reihe von zusammengesetzten Operationen [PUTROOTFH, LOOKUP, LOOKUP, ..., LOOKUP, OPEN]. Dies spiegelt Plan9s 9p sowie SMBv2/3 wider.

(All dies impliziert, dass bei diesem Stil die exportierten Dateisystempfade relativ zur Wurzel werden, z. B. wird Ihr /exports/home als "foo:/home" gemountet,nichtals „foo:/exports/home“.)

Das Fehlen einer MOUNT(path)-Operation ist auch der Grund, warum "crossmnt" impliziert wird, daist nichtWenn nichts mehr gemountet werden muss, muss lediglich von der Wurzel aus nach unten „LOOKUP“ durchgeführt werden.

In der Praxis kann NFSv4 beide Stile verwenden – wenn kein "fsid=0"-Export definiert ist, der Linux-Kernel (2.6.33 oder höher)generiert automatisch eine virtuelle/ Wurzel für Siedas nichts außer Mounts für Ihre regulären exportierten Speicherorte enthält. (Dies hat auch den Vorteil, dass die Mount-Pfade zwischen NFSv3 und NFSv4 identisch bleiben.) Mit anderen Worten: Sie können Ihre ursprüngliche Konfiguration im v3-Stil wirklich weiter verwenden.

verwandte Informationen