[hydrixOS] : Re: HydrixOS Treibermodell - Kritik gesucht :-)

  • From: Friedrich Gräter <webmaster@xxxxxxxxxxx>
  • To: hydrixos@xxxxxxxxxxxxx
  • Date: Fri, 30 Aug 2002 17:49:04 +0200

Dimitri Roschkowski schrieb:
> 
> 
> User 1 öffnet eine Datei.
> User 2 öffnet die selbe Datei
> User 1 editiert die Datei und speichert diese ab
> User 2 editiert die Datei und überschreibt alle Änderungen, die User1 
> gemacht hat, weil er noch die alte Version im Speicher hat.
> 
> Dieses Problem ist nicht einfach nur "erfunden", ich war schon 6 Mal in 
> der Situation, dass meine Dateien überschrieben wurden.
> 

Ein bekanntes Problem. Es gibt dafür die Lösung mit sog. "kritischen 
Bereichen" - d.h. nur ein Prozess darf gleichzeitig die Ressource 
(welcher Art) nutzen. Damit nicht ein Prozess 'aushungert' gibt es 
verschiedene Modelle, das Problem zu lösen.

> Als Lösung würde ich vorschlagen, dass wir noch 2 weitere "Rechte" 
> hinzufügen. Ich weiß jetzt nicht, was das Sperrrecht ist, aber man 
> sollte eben ein Recht einbauen, dass man den Lese/Schreib Zugriff für 
> bestimmte Dateien sperrt. 

Also eine Datei kann exklusiv für einen Prozess geöffnet werden? Wenn 
ja, ist es genau das Sperrecht: Man könnte das Sperrecht analog von den 
kritischen Bereichen der globalen Segmente auf die Dateien übertragen. 
(Ich weiß ich rede momentan noch in rätselhaften Begriffen, da das 
Handbuch zwar schon geschrieben ist, aber noch nicht öffentlich) D.h. 
wenn der Benutzer das Recht hat, darf einer seiner Prozesse die Datei 
exklusiv für sich öffnen und andere Benutzer/Prozesse konnen dies dann 
nicht mehr. Wichtig ist hier, dass dieses Modell nur dann eingesetzt 
werden darf, wenn tatsächlich nur ein Prozess zugreifen darf - und nicht 
bei Strategien, bei denen mehrere Prozesse zugreifen dürfen (beispiel 
wäre hier die Konsole, die von mehreren Prozessen genutzt werden können 
muss).

> Für root sollte das Recht 
> auch gelten, weil sich einige User auch als root einloggen und auf dem 
> System als root die Arbeit eines einfachen Users erledigen. 

Unter HydrixOS wäre es admin und root. Im HydrixOS-Handbuch wird das 
erst erwähnt, daher kann es noch keiner wissen: Also kurz und bündig: 
"root" ist unter HydrixOS der Benutzer in dem alle Prozesse laufen, die 
in anderen Systemen im Kernel-Modus arbeiten (der HydrixOS-Kernel läuft 
außerhalb der Benutzerdefinition, da er diese erst erzeugt :-) ). 
"admin" ist unter HydrixOS vergleichbar mit dem root unter UNIX.


> Da man root 
> aber trotzdem die Kontrolle über die Dateien des Users geben sollte, 
> halte ich eine komplette Sperrung für unsinnig. Deshalb würde ich eher 
> für sinvoller halten, dass root das Recht hat, das Recht wieder zu 
> deaktivieren und die Datei löschen kann.

Dieses Recht ist admin und dem Dateibesitzer (also diejenigen Benutzer 
mit dem Besitzer-Recht) gegeben. (root als Kernel-Benutzer sowieso). 
Wobei das natürlich abhängig vom jeweiligen Dateisystemserver ist, da 
dieser ja Dinge wie Zugriffslisten für das einzelne Dateisystem 
implementiert - der Vermittlungsserver bzw. die Dateisystem-API fordert 
ihn nur dazu auf, dass sich das enthaltene Dateisystem nach außen hin

> Ein weiteres "Recht", welches ich vorschlagen würde, währe ein "Backup 
> Recht". Wie schon oben erwähnt, passiert es wirklich sehr oft, dass eine 
> Datei überschrieben wird. Es passiert aber auch öfters mal, dass man 
> selber Änderungen an einer Datei vornimmt, und damit ein Programm 
> zerstört. Deshalb würde ich auch noch dieses Recht vorschlagen. 
> Realisieren würde ich das so: Wenn eine Datei überschreiben wird, die 
> das entsprechende Flag für das Backup Recht hat, dann wird vorher eine 
> Kopie im home verzeichniss irgendwo gespeichert. z.B. befinden sich dann 
> unter "/home/username/backup/testfile.txt.versionsnummer" 10 Versionen 
> der Datei. 

Also eher ein Datei-Flag (also so etwas wie Schreibschutz, Verstecken usw.).

> Ich weiß jetzt nicht, wann man das besser realisieren 
> kann/soll. 

Hm das ist schwierig. Entweder führt man einen seperaten Backup-Server 
ein, den die Dateisystemserver informieren können (Treiber, die ihre 
Schnittstellen auch als Dateien anbieten, müssen ja dieses Backup-Flag 
ignorieren) oder die Dateisystemserver organisieren dies selbst mit 
Hilfe des zentralen Vermittlungsservers.

> Ich kann sein, dass man diese Funktion auch noch später 
> einbauen kann, aber ich finde es wichtig, wenn man solche Sachen gleich 
> bespricht, und nicht erst dann, wenn alles zu spät ist.
> 

Womit du auch Recht hast, denn diese Sache müsste man bereits in der 
Dateisystemschnittstelle einbauen - wenn sie den Bestandteil des 
Dateisystems seien soll.

Das Problem ist, dass wir eine Art universelles "virtuelles" Dateisystem 
erschaffen müssen, an das sich dann andere Dateissysteme (und 
Gerätetreiber) einhängen können. D.h. dieses Dateisystem ist insofern 
"virtuell", da es nur zum Entwurf der Dateisystemschnittstelle dient.

cu

FG

-- 
HydrixOS Developers Mailing List

Administration: webmaster@xxxxxxxxxxx 
Archive: http://www.freelists.org/archives/hydrixos

Other related posts: