Lowlevel
Lowlevel => OS-Design => Thema gestartet von: SilverKnight am 22. December 2005, 09:20
-
Hi.
Ich hatte in den letzten Tage ein paar Gedanken zum Thema "Benutzer - DAU - Profi - ..." im Zusammenhang mit Datenzugriff.
Ich möchte von einigen anderen Personen die Ahnung von dem Gebiet OS Entwicklung haben mal wissen, wo die Grenzen für Verständnis stecken, ihrer Meinung nach.
Beispielsweise: Das Dateisystem erlaubt NIEMANDEN in OS-Daten, Programmdaten, treiber einzusehen. Der einzig sichtbare Teil des Dateisystems wären halt die Benutzerdateien. Der Rest wird geschützt vom System verwaltet und ist und bleibt nicht einsehbar.
-> Wie das ganze zu realisieren wäre lasse ich mal aussen vor, es geht mir rein um die Theorie, wie der Benutzer sich verhalten KÃNNTE. <-
Ich sperre den Benutzer sozusagen in die eigenen Dateien ein. Höher berechtigte Benutzer "root, Admin, whatever...", können natürlich in alle Dateien der Benutzer einsehen.
Ich denke mal das erklärt meinen Gedanken.
Ich wäre mir aber nicht sicher wie der Benutzer bei so einem Konzept reagiert? Kein Vertrauen, weil er nicht alles sieht? (Verschwörungstheorie ^^) --- Zufriedenheit - da es sehr einfach und übersichtlich zu bedienen wäre...
Für Meinungen / Kritik wäre ich Dankbar.
Silver
-
Das wäre eine gute Idee, denn so wäre das System auch gegenüber Viren viel sicherer.
Ich als Benutzer würde mich nicht aufregen, sofern man das System über ein einziges gut strukturiertes Einstellungsmenü mit vielen Einstellungen konfigurieren kann.
Ich werds warscheihnlich auch irgendwie so machen.
Gruss
Nooooooooos
-
THX für die Antwort.
Ziel ist es, dem Benutzer eine einfache Struktur vorzulegen. Diese einfache Struktur soll natürlich weniger Angriffsfläche als ein aufwändiges Dateisystem bieten, da ja nur die Benutzerdateien "öffentlich" liegen und durch ein sehr simples Rechtesystem geschützt werden (das ist in meinem Plan noch nicht ausgereift - ich mache mir z.Zt. eher sorgen zu meinem Jetzigen "Ideen-Stand" die interne umsetzung zu machen.
Nur mit den vielen Einstellungen bin ich auf dem Kriegspfad (Muss der Benutzer denn wirklich jedes Detail einstellen dürfen / können?). Was würdest du denn an "vielen Einstellungen" vermissen?
Silver
-
Nun ja, beim Dau könnte ich mir auch Verwirrung vorstellen wenn es mal so (wenn er es normal benutzt) und mal so (wenn er doch mach als "Admin" arbeiten muss) aussieht.
-
Nutzer, die sich ein bisschen besser auskennen, werden es warscheinlich einfach praktisch finden, ihr System so anzupassen, dass sie schnell und unkompliziert arbeiten können.
Man könnte ja zwei Einstellungsmenüs machen, eins für Anfänger, dies gern einfach haben und eins für Professionelle Nutzer.
Gruss
Nooooooooos
-
huhu, mach doch einfach 2 Root Directorys; eins fürs System und das andere fürn User;
So mach ichs und so stehts auch in meinen aktuellen Tutorial über Dateisysteme (OS developing Theorie I)
Und dann könntest du ev. im User Root Directory ein Ordner (z. B. C:\System) mit dem System Root Directory linken.
lg,
Toaster
-
@Legend:
ROOT Ansicht:
/Benutzer A
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Benutzer B
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Ãffentlich
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Netzwerkumgebung
/DVD-Laufwerk
/DVD-Brenner
/USB-Stick
Benutzeransicht "Benutzer A":
/Eigene Dateien
/Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Ãffentlich
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Netzwerkumgebung
/DVD-Laufwerk
/DVD-Brenner
/USB-Stick
Natürlich alles als Tree ansicht.
So sollte das nicht verwirren. Der Admin / Root bekommt keine Eigenen Dateien um zu verhindern, dass er als normaler Account genutzt wird. Auch der Admin sollte sich einen normalen Benutzer anschaffen.
@nooooooooos:
So wie oben dargestellt ist es schnell zugänglich, effizient und der Benutzer kann seine Dateien und Verzeichnisse unterhalb von "Eigene Dateien" selber verwalten wie er möchte.
@T0ast3r:
Wie gesagt, wie das intern aussehen soll bin ich mir noch ganz und gar nicht sicher. Ich überlege schon seit Tagen rum wie sich die Daten am effizientesten legen lassen, und zwar so, dass sie von mir (oder sonstigen OS Entwicklern) unkompliziert genutzt werden können (also die Nutzung leicht und effizient programmieren lässt).
Nur dass der Benutzer halt im Dateisystem nichts vom System und den Programmen wiederfindet. Dazu wird es in der Konfiguration "ala Systemsteuerung" Einträge geben, Programme zu entfernen, Systemeinstellungen zu verändern (die sowieso in /Benutzername/Programmdaten/System bzw im AllUsers / Ãffentlich Ordner (oder ähnlich) liegen.
-
Ich glaube, wie das ganze intern verwaltet wird, ist relativ egal. Das entscheidene in dieser Frage ist eher, wie das Dateisystem dem Benutzer präsentiert wird. Windows macht es ja vor: Der Desktop liegt zwar in irgendeinem Unterverzeichnis herum, wird aber von den Benutzern trotzdem als oberste Ebene angesehen, weil er eben so präsentiert wird.
Wie der Verzeichnisbaum jetzt aber konkret aussehen muß, kann man sich sicher beliebig lang streiten.
-
Ich glaube, wie das ganze intern verwaltet wird, ist relativ egal. Das entscheidene in dieser Frage ist eher, wie das Dateisystem dem Benutzer präsentiert wird. Windows macht es ja vor: Der Desktop liegt zwar in irgendeinem Unterverzeichnis herum, wird aber von den Benutzern trotzdem als oberste Ebene angesehen, weil er eben so präsentiert wird.
Wie der Verzeichnisbaum jetzt aber konkret aussehen muß, kann man sich sicher beliebig lang streiten.
Da hast du irgendwie recht. Wenn ich meine Idee / Konzept so realisieren würde, würden sich die Benutzer langsam daran anpassen, solange es wirklich nicht nach Verschwörung, etc, aussieht.
-
Was ich auf keinen Fall machen würde, ist den normalen Benutzern jeden Zugriff auf die System- und Programmdateien zu verbieten. Ansonsten landen am Ende alle Programme bei den Daten, weil jeder Zugriff auf alles haben will, egal, ob er sich eigentlich genug damit auskennt. Die einzige Möglichkeit, das zu verhindern, wäre, in dem Datenverzeichnis grundsätzlich keine Programme auszuführen. Dann wiederum stelle ich es mir relativ problematisch vor, Software auf diesem System zu entwickeln...
Gegen den Benutzer arbeiten und ihn künstlich einschränken, funktioniert nicht, denn dann wird er immer um die Sicherheitsmechanismen herumarbeiten.
-
Eigentlich wollte ich jetz mit so nem Kommentar werfen wie "Hast du alles gelesen?" Aber da ist mit eingefallen, dass ich diese Informationen nicht geschrieben hatte.... Sollte eigentlich der zweite Post werden, aber ich hatte mich aus irgend einem vergessenen Grund dafür entschieden, es nicht zu schreiben. Also dacht ich ich hätts geschrieben aber ... ^^:
Ich nenne das Dateisystem nicht Dateisystem, sondern Festplatten-Management-System. Das Dateisystem ist einer von 3 Bereichen (Der einzige direkt sichtbare).
Das Betriebssystem ist ein Teil (Modulare erweiterung (Treiber, etc), und die Programme ("Programm-Packete") bilden den zweiten. Der Zweck ist, dass diese nicht sichtbar sind und nicht zum "Dateisystem gehören". Programm-packete werden durch einen vom System bereitgestellten Installer hinzugefügt.
Das Nachteil ist klar: jedes noch so kleine Programm (auch selbstgeschrieben) muss beim Betriebssystem registriert werden. Der Vorteil wenn nur registrierte Programme ausgeführt werden können: Maximale Sicherheit und leichtes Management (u.A. Rechteverwaltung durch Root).
Sry, dass ich vergessen habe das zu cshreiben. Ich denke über das Konzept so viel nach, und ich bin von Natur aus so zerstreut... Lassen wir das ^^
So, jetz nochmal deine Meinung taljeth (und die anderen) ;)
THX
Silver
-
Das Nachteil ist klar: jedes noch so kleine Programm (auch selbstgeschrieben) muss beim Betriebssystem registriert werden. Der Vorteil wenn nur registrierte Programme ausgeführt werden können: Maximale Sicherheit und leichtes Management (u.A. Rechteverwaltung durch Root).
Sehr unpraktisch, finde ich... Das garantiert zwar fast 100%ige Sicherheit vor Viren, allerdings wird so auch niemand für dein System entwickeln, vorallem keine Hobby-Coder oder so. Und du musst ständig dein OS updaten. Oder zumindest die Tabelle, in der alle registrierten Programme stehen. Das bremst die Entwicklung/Benutzung eines OS enorm. Sollte es aber trotzdem "groß" werden, so wird man schnell Hacks finden, die die Tabelle entsprechend manipulieren um neue Programme installieren zu können.
-
Sehr unpraktisch, finde ich... Das garantiert zwar fast 100%ige Sicherheit vor Viren, allerdings wird so auch niemand für dein System entwickeln, vorallem keine Hobby-Coder oder so. Und du musst ständig dein OS updaten. Oder zumindest die Tabelle, in der alle registrierten Programme stehen. Das bremst die Entwicklung/Benutzung eines OS enorm. Sollte es aber trotzdem "groß" werden, so wird man schnell Hacks finden, die die Tabelle entsprechend manipulieren um neue Programme installieren zu können.
Wo genau siehst du die Propleme beim Entwickeln?
-
Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?
-
Das ist mir auch im Kopf. Ich überlege schon krampfhaft eine Lösung ohne das Konzept komplett überarbeiten zu müssen. Vielleicht nen Modus den der Root anschalten kann wo es auch erlaubt ist, WindowsEXE oder Linux* zu starten... Was weiss ich. Muss ma drüber nachdenken.
-
Oder wie wäre es mit Patches? Man entwickelt ein Programm neu, compiliert zum Packet, installiert, testet, erstellt weiter, compiliert, erstellt n Patch vom Original zum NeuPacket (automatisiert vielleicht (Script, etc)) und patcht dann die Anwendung. Wäre auch ne ersparnis (vielleicht alles direkt automatisieren, wenn das OS erkennt dass das Programm Debugbar ist, oder sowas.....
*aufschreib*
Muss ma Ideen sammeln und vergleichen
-
Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?
Achso, ich dachte man müsste das Teil dann beim Entwickler des OS "registrieren", damit der das in seine Tabelle aufnimmt...
-
Du könntest es ja so machen, dass eine Programmdatei (z.B .com) eine ganz normale Datei ist, wie eine Textdatei usw. Aber wenn man sie anklickt wird sie nicht gestartet, sondern ein Installer (vom OS bereitgestellt) gestartet, welcher sie in die Tabelle aufnimmt.
Dann wäre es einfacher für Entwickler.
Gruss
Nooooooooos
-
Hm, den größten Teil des Aufwands beim Kompilieren/Installieren kann sicher eine Entwicklungsumgebung übernehmen. Aber wenn ich bei jedem Kompiliervorgang das Adminpaßwort eingeben müßte, würde ich mir leicht verarscht vorkommen. Und wenn die Paßworteingabe nicht nötig wäre, wäre das ganze Sicherheitskonzept schon wieder unterhöhlt.
Darf man übrigens mal nach der "Zielgruppe" fragen? In einem echten Mehrbenutzersystem würdest du Softwareentwicklung komplett unterbinden, denn da hat garantiert nicht jeder Adminrechte. Außerdem möchten die meisten Benutzer wohl ab und zu auch mal selbst kleinere Programme installieren, die der Admin nicht vorgesehen hat - in meinem Homeverzeichnis in der Uni liegt da auch das ein oder andere rum.
Eine mögliche Lösung wäre es, jedem Benutzer neben einem Daten-Verzeichnis auch ein Programm-Verzeichnis zur Verfügung zu stellen, in das er installieren kann. Das wäre dann aber eine Lösung, die ausschließlich auf die Übersichtlichkeit abzielt, die Sicherheit wäre wieder dahin. Nur: Wenn du eine solche Möglichkeit nicht schaffst, werden deine Benutzer rebellieren und entweder ein anderes System benutzen oder sich irgendwelche Tools besorgen, die das erledigen. ;)
Nachtrag: Ja, ich weiß, wer lesen kann... Wenn du also sowieso für die Benutzer ein privates Programmverzeichnis vorsiehst, brauchen wir über die Sicherheitsthematik natürlich nicht mehr reden. Und da sehe ich dann auch einen Widerspruch in deinen Aussagen.
-
Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?
Achso, ich dachte man müsste das Teil dann beim Entwickler des OS "registrieren", damit der das in seine Tabelle aufnimmt...
Nun, das wär dann halt noch schlimmer.
Ich glaub der Teil lohnt sich nur für System auf denen nicht entwickelt werden soll. Kurz um, ich glaub Entwickler werden sowas abschalten müssen.
-
Das mit dem "registrieren" meine ich, dass das Betriebssystem nur Programme starten lässt die installiert worden sind.
Ausführbare Dateien wird es generell nicht geben. Für Installationen werden Archive speziellen Formates benutzt. Wie z.B: mit MSI Dateien unter Windows oder den RPMs unter einigen Linux'es.
Der Admin kann natürlich einzelnen Benutzern mehr Rechte geben. z.B. wenn man sich eine Familie vorstellt, dürfen Mutter und Vater Sachen installieren. Die Kinder dürfen nichts installieren und nur Programme ausführen, die ihrem Alter entsprechen (FSK USK Prüfung anhand des Geburtsdatums, wo die Eltern den Kindern das Recht enziehen können, persönliche Informationen zu ändern).
Ein Rechte / Erlaubnisystem füs Betriebssystem sollte es schon geben, nut halt vereinfacht für Dateien.
Mit den selbstentwickelten Programmen dachte ich es mir so, wie es schon erwähnt wurde: Die Entwicklungsumgebung kann das Programm selbstständig Installieren, allerdings ist es nur für den Benutzer startbar und wenn es im Debugmodus läuft, weiter eingeschränkt, damit nix kaputt gehen kann.
Zur Installation berechtigte Benutzer können auswählen, für wen welches Programm ausführbar sein soll, Features, etc........; solange sie im Release Status sind. Debug-Programme werden als "In Entwicklung" angesehen und werden zusätzlich eingeschränkt, falls es Fehlfunktionen gibt.
Natürlich sind Details noch zu überdenken.
Frohe Weihnachten und guten Rutsch wünsch ich euch ausm Urlaub.
Silver
-
Verstehe ich es also recht, daß es unmöglich ist, Programme von CD, von USB-Stick oder von einem Netzwerkserver laufen zu lassen, sondern man sie erst lokal installieren muß?
-
huch, das wäre aber nicht sehr benutzerfreundlich....
-
Wie es mit der Netzwerktechnik aussehen soll in dem Bereich weiss ich noch nicht. Wenn es etwas "Domänen" ähnliches gäbe wären Anwendungen ausm Netzwerk sicher nicht das Problem. "Arbeitsgruppennetzwerke" wären wieder eine Sicherheits-Frage. Wer weiss was da drin is. Und ausserdem wäre eine Installation da auch nicht so aufwändig.
Anwendungen vom USB Stick... OK, optische Medien kommen auch dazu... Muss ich mir mal durch den Kopf gehen lassen. Zum CD Autostart hatte ich mir gedacht, HTML zu verwenden.
Jemand ideen? Muss mir mal den Kopf zerbrechen.
Silver
-
Zum CD Autostart hatte ich mir gedacht, HTML zu verwenden.
WTF? HTML?
-
Ala HTA
-
hm ok, ist eine möglichkeit. die frage ist jetzt ob das flexibel genug ist. man könnte den autostart auch so organisieren, dass auf der cd eine art content-type vermerkt wird (besser: das system erkennt ihn selbst), und dann stellt das system fest, ob es den video player, den mp3 player, den fotoalbum betrachter, das brennprogramm, den installer, etc. starten soll.
-
Was hat Autostart überhaupt mit dem Thema zu tun? Ist das nicht etwas, was man unabhängig von der Organisation des Dateisystems angehen kann, wenn man es denn überhaupt haben will? Sollte es nicht erstmal möglich sein, alles von Hand zu starten?
-
Ich finde es hängt zusammen. Wenn das Dateisystemkonzept (ich nenne es singemäß lieber Festspeicher-Management-System) es verbietet "Dateien" auszuführen, sondern es nur erlaubt durch Pachet-Dateien auf dem Rechner installierte Softwarepackete zu starten... Wie löse ich dann einen CD Autostart, oder Software über Netz bzw. USB Stick. Da spielt doch ein FMS (Festspeicher-Management-System) eine wichtige Rolle.
Naja, wie man es auch sehen mag - ich geh schlafen und dann mir den Kopf weiter zerbrechen wie man das ganze lösen kann.
THX for Posts
Silver
-
Das Prinzip mit den Modulen hat mir eigentlich nicht schlecht gefallen. Ich habe mir gedacht, dass beim System ein Bereich für Programme ist, einer für das OS und einen für den User. Der User kann aber nicht auf die anderen Teile zugreifen bzw. sieht die nicht einmal. Wenn dann ein Programm welches sich im User-Bereich befindet ausgeführt wird stört doch das das System nicht. Das Programm kann ja gar nicht auf Systembereiche zugreifen da der User die gar nicht kennt.
mfg, jeb
-
Aber was ist mit den Userdateien? Dann müsste man dem Programm ja auch verbieten, auf die Eigenen Dateien zuzugreifen (Der Sicherheit wegen).
Da jedes Programm nur auf seine eigens erstellten Dateien im Anwendungsordner (siehe weiter unten) zugreifen darf, wäre das ja nicht das Thema.
Add zum User-Bereich wie ich es mir gedacht hatte (Anwendungsdaten);
\
\Username 1\
\Username 1\....
\Username 1\Eigene Dateien\
\Username 1\Eigene Dateien\....
\Username 1\Eigene Dateien\Eigene Bilder\
\Username 1\Eigene Dateien\Eigene Bilder\.....
\Username 1\Anwendungsdaten\
\Username 1\Anwendungsdaten\Officeprogramm\
\Username 1\Anwendungsdaten\Officeprogramm\.....
\Username 1\Anwendungsdaten\Malprogramm\
\Username 1\Anwendungsdaten\Malprogramm\.......
\........
und so weiter
Der Admin (bzw. andere Berechtigte) sollten natürlich ind er Lage sein per COmputer / per User bestimmen zu können, ob nicht installierte Programme ausgeführt werden dürfen, ob sie Dateien anlegen dürfen, etc.
Weitere Ideen?
THX
-
IMHO muss jedes User Programme auf alle User Dateien zugreifen dürfen. (Wenn das nicht so wäre, würde ja nichtmal das kopieren einer Datei funktionieren.)
Auf die Systemdateien müssen normale User eh nicht zugreifen und daher kann man diesen Zugriff verbieten. Ausserdem sollten die User soviel wie möglich an ihrem eigenen Konto ändern können, ohne ein admin/root Account zu besitzen.
Das Installieren der Programme ist eine gute Idee, das System könnte eine Liste aller installierten Programme führen, quasi ein Packetmanagement das fest im System verankert ist.
Programme die keinen Schaden anrichten können, können ja weniger Rechte kriegen, aber dafür auch von jedem User ohne zustimmung des Admins installiert werden. Die Autostart Programme können auch weniger Rechte kriegen.
Programme aus dem Netzwerk oder von Wechseldatenträgern würden sich ja auch leicht installieren lassen.
-
IMHO muss jedes User Programme auf alle User Dateien zugreifen dürfen. (Wenn das nicht so wäre, würde ja nichtmal das kopieren einer Datei funktionieren.)
Klar worauf du hinaus willst. Was nützt ein Office wenn man nix speichern kann. Sobald auf die Eigenen Dateien zugegriffen werden soll wird der Benutzer einmal gewarnt und kann dann sagen "Ja, Nein, Einstellung für Programm speichern" und gut ist. Später kann er z.B: in der Systemverwaltung das ganze ändern. Mir ging es explizit um uninstallierte Programme. Wenn das Programm nicht installiert ist, darf es das nicht. Ausnahmen sollte es da nicht geben. Dies wäre nur wieder ein mögliches Sicherheitsproblem.
Auf die Systemdateien müssen normale User eh nicht zugreifen und daher kann man diesen Zugriff verbieten. Ausserdem sollten die User soviel wie möglich an ihrem eigenen Konto ändern können, ohne ein admin/root Account zu besitzen.
Systemdateien wird es, bis auf Einstellungsdateien, ja nicht geben. Nur halt den Systembereich. Und der ist und bleibt ja gesperrt (Einziger zugriff hat das System selbst (nur lesend, ausser Updates, Treiberintall, ...)) - Natürlich kann ein User sein Profil einstellen wie er es möchte. Dazu unten mehr.
Das Installieren der Programme ist eine gute Idee, das System könnte eine Liste aller installierten Programme führen, quasi ein Packetmanagement das fest im System verankert ist.
So wars gedacht
Programme die keinen Schaden anrichten können, können ja weniger Rechte kriegen, aber dafür auch von jedem User ohne zustimmung des Admins installiert werden. Die Autostart Programme können auch weniger Rechte kriegen.
Meine Idee dazu: Installationspackete enthalten Informationen wie z.B. Betzwerkbenutzung auf Port XY, ... Zugriff auf Eigene Dateien nötig, ..... Bla. Während der Installation sieht der Benutzer und das System das und die Rechte können schon während der Installation direkt geändert werden, ohne lästig in der Systemverwaltung alles selbst zu machen. z.B. kann je nach bedarf für ein Spiel der Netzwerkport geöffnet werden. Das System erledigt das ganze. Der Benutzer muss lediglich bei der Installation sagen "Ja, Nein, für Immer merken" und gut ist. Der Port bleibt dann immer zu, solange bis das Programm diesen anfordert. - Der Systeminterne Packetfilter wäre geboren. Das nur als kleine Idee. Was sich aus diesem bereich so rausholen lässt wäre zu diskutieren.
Programme aus dem Netzwerk oder von Wechseldatenträgern würden sich ja auch leicht installieren lassen.
Das ist mein Gedanke. Wenn jemand ein programm nutzen will, soll er es installieren. Wozu aus dem netz starten? OK - für Domänennetzwerke würde es da sicher einen Mechanismus geben (Server hält Programm bereit für Netzwerkstart oder automatische Installation). Aber nehmen wir mal an man kommt zu einer LAN Party oder sowas. "OH, Cooles Spiel - Gib ma". Und da geht das Kopierschutzgemalme wieder los. - Wenn es aber erst am System installiert werden muss, kann während der Installation die Gültigkeit, etc.... geprüft werden. Alterseinstufung vom System gecheckt werden, Bla... Meiner Meinung nach ist der Bedienungskomfort einer der Aspekte, der am wenigsten Minuspunkte bei diesem Konzept einfährt. Auf die Wage legen mit Systemsicherheit, Kommerz-Sicherheit, ... finde ich ist das schon zu akzeptieren. Vielleicht bei Gigabyte-Programmen könnte es etwas nervend sein... Aber die Idee ist ja noch nicht zuende gedacht.
Ich wollte noch kurz zur Benutzerhirarchie was sagen.
Es soll nicht EINEN Root geben, sondern die Möglichkeit Rechte zu vererben.
Ich sehe gerne auf eine 4-köpfige Familie zurück.
Vatter installiert das System. Er erstellt das Konto "Dad" und gibt sich maximale Rechte (natürlich hat er dann nicht so viele wie Root, aus Sicherheit sollten einige trotzdem das Root-Passwort erfordern). Das Mann im Haus darf also den Rechner verwalten. Die Mutter möchte auch einiges am Rechner machen - Bekommt also auch viele Rechte.
Die Zwei Kinder: Der Junge 10, die Tochter 17 jahre alt. Die Eltern richten die Profile ein, in denen steht wann sie geboren sind. Erstmal wird den Kindern verboten, Private einstellungen zu ändern (wie Geburtsdatum). Wenn nun der Sohn eine Horror-Metzel-DVD einlegt, sagt ihm das System freundlich "NEIN" oder wenn er versucht ein Programm zu installieren - "NÃ". Für die Tochter fehlt beispielsweise nur das Recht, Software zu installieren. Spiele sind OK, aber keine Programme (nur als Beispiel). DIe Tochter installiert das Spiel ab 16, der Sohn kann es aber wieder nicht starten. - Der Sohn hat jetz aber ein Spiel für 8 Jahre. WIll es installieren - Der Vater hat die zweite Möglichkeit gewählt: Der Sohn darf am System anfragen, ob die Software installiert werden darf. - Das Packet wird von der CD auf die Festplatte kopiert, aber es darf solange nicht ausgeführt werden, bis ein autorisierter Benutzer das Erlaubt hat (z.B: Mutter). Die letzte Methode würde sich im Unternehmen auch als sehr praktisch erweisen. Mitarbeiter 044 möchte ein Packprogramm installieren. Der Computer sagt "Möchten Sie beim Admin anfragen?" - Der Benutzer gibt einen Kommentar ein und sagt "Ja". Programm wird kopiert und bleibt gesperrt - Eine Nachricht wird zu einem autorisierten in der EDV Abteilung geschickt. Er liest sich die Anfrage durch und braucht nur auf "Ja oder Nein" zu klicken. Der Benutzer wird über die Entscheidung benachrichtigt und bei NEIN fliegt das Programm automatisch wieder runter. Genau so mit Internetrechten, etc - Aber das hat jetzt weniger mit Festplattenrechten / Extene Median Rechten zu tun.
Das heisst, jeder Benutzer kann Rechte verschrieben bekommen von darüberliegenden Ebenen. Auf diese Rechte verzichten kann er natürlich selber, indem er sie sich wieder wegnimmt. - Einige Rechte sind altersbedingt einstellbar (wie im beispiel bei Familien - wenn gewünscht) oder weitere Möglichkeiten.
Das System soll von den Rechten her relativ einfach gestaltet werden. Nicht zu viele Einstellmöglichkeiten (generell vom System nicht allzu viele und z.B. diese Ausblenden, die ein Benutzer eh nicht hat (oder zumindest die Steuerelemente deaktivieren)) - Das wahrt die Übersicht und Bedianbarkeit. Aber zu wenig natürlich auch nicht. Ziel soll es sein, möglichst viel selber entscheiden zu können aber nicht zu unübersichtlich zu werden. Es muss nicht jedes Details sperrbar sein (wozu den Bildschirmschoner sperren oder verhindern, dass der Benutzer die Farben ändern kann?) Was es an Einstellungen gäbe würde sich während der konkreten Systemplanung zeigen.
Natürlich sind im System auch Benutzergruppen anlegbar.
Detailierte Lösung bzw. Entwicklungswege sind dabei noch nicht mit reingedacht ;)
Silver
-
Ich hab mir das 3-Bereiche Konzept mal intern vorgestellt.
Linux nutzt ja die Partitionen sehr aus, während Windows sich auf einer Partition begnügt. - Was wäre für diese 3 Bereiche Sinnvoll?
Partitionen? Wären zu starr. Woher soll ein Benutzer wissen wie viel von seinen 500GB er wie nutzt?
LVM? Ich denke das wäre wie die Geschichte mit den Kanonen und Spatzen - zumindest für die Anfangsphase. Unterstützung wünschen tät ich mir schon.
Zu der bisherigen Idee:
1 Partition. Die Partition trennt sich in Blöcke auf: 1 Block = 1 MB.
+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11| 12|
| | | | | | | | | | | | |
| | | P | | P | P | P | | | | | |
| S | S | | S | | | | | | | | |
| | | | | | | | u | u | U | U | U |
+---+---+---+---+---+---+---+---+---+---+---+---+
S = System
P = Programme, ...
U = Benutzerdaten belegt
u = Benutzerdaten frei / generell frei
Die Blöcke sind vom Geburt an alles u Blöcke, also für den Benutzer verfügbar und frei.
Das System installiert sich in Block 1 (am Anfang der Partition | Bootsektor) und folgende (im Beispiel 1 und 2)
Dann installier der Benutzer ein Programm. Ein P Block wird belegt. Weiterhin folgt ein Trieiberupdate / Systemupdate - Wieder ein S belegt und dann kommt noch Software hinzu (3 Ps) und der Benutzer kopiert seine Dateien drauf (insgesamt 3 Us, am Ende anliegend).
Das Prinzip ist folgendes: Ich würde es mit Paging vergleichen wollen (ich hoffe ich vergleiche das richtig). Würde man es ähnlich dem NTFS lösen, würde man einen riesigen Leerbereich erhalten, aufgrund der Blockgrösse. Ich würde es mappen: 3 Bereiche: Gehen wir von P aus:
Megabyte 0 fängt bei 3 oben in der Tabelle an. Megabyte 1 fängt bei 5 an.
Die Listen würden also so aussehen:
P Sektor
0x00000000 - 6144
0x00100000 - 10240
0x00200000 - 12288
0x00300000 - 14336
Vielleicht wäre es auch Sinnvoll, aneinanderliegende Blocke nicht in der Liste aufzuführen, also anzugeben, wie viele aufeinanderfolgende es sind.
Ich hoffe da sind keine Rechenfehler bzw. Denkfehler enthalten.
THX for feedback
Silver