[linux-l] Re: /proc & Co.

[olafBuddenhagen at gmx.net]

Hallo,

On Sat, Oct 21, 2006 at 10:42:54AM +1000, Peter Ross wrote:
> On Fri, 20 Oct 2006, olafBuddenhagen at gmx.net wrote:

> > Bei Linux sind es tatsächlich Hacks, aber von der Idee her garnicht
> > so falsch. Dateisystem-basierte Schnittstellen sind sehr oft
> > praktisch und sinnvoll.
> > 
> > Schade dass es keinerlei Standards dafür gibt, und dass die
> > Linux-Entwicker es auch nicht für nötig befinden, sie einiger maßen
> > stabil zu halten...
> 
> Es ist einfach nicht moeglich, da sich die Funktionalitaet und
> Implementation des Kernels sich bestaendig aendert. Ein starres
> /proc-Konzept ist ein zu enges Korsett. Daher die sysctls, die solche
> Aenderungen "stabilisieren" (fuer den Nutzer).

Freilich, es gibt Argumente für stabile vs. temporäre Schnittstellen.
Und es gibt auch gute Gründe, wieso für die temporären klassische
syscalls ungeeignet sind. Ich sehe aber den Umkehrschluss nicht: Was
spricht denn dagegen, auch stabile Schnittstellen als Dateisystem zu
exportieren und zu standardisieren?

> > > FreeBSD z.B. hat das gesamte /proc entsorgt, vorallem aus
> > > Sicherheitsgruenden.
> > 
> > Kann ich nicht nachvollziehen. Warum sollten syscall-basierte
> > Schnittstellen sicherer sein?
> 
> Weil es ein exakt definierter Eintrittspunkt in den Kernel ist.
> Zugriffskontrollen und -beschraenkungen sind hier einfacher unmd
> uebersichtlicher zu handhaben als ein bestaendig exportierter Teil der
> Kernelinformationen im Userland.

Bei Dateisystem-Aufrufen ist der Eintrittspunkt genauso exakt definiert,
nur dass er sich an einer anderen Stelle befindet. (Nicht im Code der
den Syscall selbst entgegennimmt, sondern erst in dem Code der sich um
eigentliche pseudo-Datei kümmert.)

Die Tatsache, dass die Zugriffsrechte allgemein über Dateiattribute
geregelt sind, und nicht für jeden Syscall extra implementiert werden
müssen, sollte nach meinem Verständnis die Sicherheit eher verbessern...

Das mit dem "beständig exportierten" leuchtet ein, aber ist es wirklich
so? Werden die Daten in /proc und /sys irgendwie automatisch abgelegt?
Ist es nicht eher so, dass sie erst per Callback geholt werden, wenn
eine konkrete Anfrage anliegt?... (Bei Hurd zumindest werden
Dateisystem-Zugriffe grundsätzlich über Callback gehandhabt; bei Linux
weiß ich es allerdings nicht wirklich.)

> Nebengedanke: Ein sysctl kann im Zweifelsfall schneller sein als
> filebasierte Loesungen, die zumindest zwei Operationen (open und read)
> brauchen, die ueber die VFS-Schicht zum procfs durchgereicht werden
> muss.

Freilich. Spielt aber in der Praxis in erstaunlich vielen Fällen nicht
die geringste Rolle.

(Das open() ist übrigens bei wiederholten Zugriffen eher irrelevant, da
man die Datei ja länger offen halten kann. Performance-Probleme
entstehen eher dadurch, dass man komplexe Datenstrukturen erst irgendwie
serialisieren und/oder in eine Verzeichnissstruktur abbilden muss...)

> Bei Informationen, die sich staendig aendern (z.B. zu Prozessen), wird
> es auf unterer Ebene ziemlich absurd, da man entweder eine veraltete
> Kopie offen haelt oder bestaendig neuoeffnen muss.

Das ist ein interessanter Aspekt, über den ich mir bisher keine Gedanken
gemacht habe. Prizipiell kann man den Inhalt einer pseudo-Datei ja auch
aktualisieren, wenn sie geöffnet ist. Könnte aber zu Konsistenzproblemen
führen... Wie wird das bei /proc und /sys gehandhabt? Wie geht Plan9
damit um?

-Olaf-