DE69529092T2

DE69529092T2 - Einrichtung zur sicherheit eines hauptrechnersystems mit doppeldekor

Info

Publication number: DE69529092T2
Application number: DE69529092T
Authority: DE
Inventors: S. Bianchi; S. Hirsch; B. Perry
Original assignee: Bull HN Information Systems Inc
Current assignee: Bull HN Information Systems Inc
Priority date: 1994-09-23
Filing date: 1995-09-12
Publication date: 2003-09-11
Anticipated expiration: 2015-09-13
Also published as: WO1996009705A1; EP0803154A1; DE69529092D1; US5664098A; EP0803154B1; EP0803154A4

Description

Hintergrund der Erfindung

Gebiet der Verwendung

Die vorliegende Erfindung bezieht sich auf die Emulation eines Computersystems durch ein anderes Computersystem und insbesondere auf Software-Emulation.

Stand der Technik

Mit der schnellen Evolution von Computersystemen mit höherer Geschwindigkeit und neueren Mikroprozessor-Chipdesigns haben Nutzer nunmehr sogar eine größere Notwendigkeit, ihre Anwendungsprogramme, die für ein spezifisches Computersystem geschrieben sind, auf verschiedenen Computersystemen ablaufen zu lassen. Darüber hinaus wird es wichtiger als jemals zuvor, diese Fähigkeit bereitzustellen, ohne derartige Anwendungsprogramme konvertieren oder portieren zu müssen. Daher hat eine große Anzahl von Herstellern sowohl Hardware- als auch Software-Ansätze entwickelt, um dieses Ergebnis zu erreichen, ohne derartige Anwendungsprogramme konvertieren oder portieren zu müssen.
Ein System des Standes der Technik erreicht obiges durch Bereitstellung der Fähigkeit, eine Mehrzahl verschiedener Betriebssysteme ablaufen lassen zu können. Jedes Betriebssystem hat definitionsgemäß ein inneres Dekor und wird verwendet durch eine Vorrichtung, welche die Betriebssysteme isoliert und sicherstellt, dass nur die Befehle des gegenwärtig aktiven Betriebssystems ausgeführt werden. Dieses System ist offenbart in US-Patent Nr. 4 530 052 von James L. King mit dem Titel "Apparatus and Method for a Data Processing Unit Sharing a Plurality of Operating Systems" (Vorrichtung und Verfahren für eine Datenverarbeitungseinheit, welche ein Mehrzahl von Betriebssystem teilt), erteilt am 16. Juli 1985 und dem dortigen Inhaber übertragen. Das System hat die Begrenzung, nicht in der Lage zu sein, mehr als ein Betriebssystem zu einer Zeit ablaufen lassen zu können.
Ein anderes System des Standes der Technik stellt eine Mehrzahl von Zentralverarbeitungseinheiten bereit, deren jede eng zusammengekoppelt ist und einen verschiedenen Typ von Betriebssystem verwendet. Die Zentralverarbeitungseinheiten in Kombination mit ihren Betriebssystemen arbeiten in einem Peer-Verhältnis, in welchem alle Systeme Zugriff auf alle System-Ressourcen haben. Um die Integrität des sichersten der Betriebssysteme (d. h. das als proprietär erachtete Betriebssystem) sicherzustellen, sind gewissen Mechanismen in dem System enthalten zum Durchsetzen bestimmter Restriktionen hinsichtlich des anderen, weniger sicheren Betriebssystems (d. h. die als nicht-proprietäre erachteten Betriebssysteme). Diese Restriktionen sind, dass ein nicht-proprietäres Betriebssystem nur zugreifen kann auf Speicher, der durch das proprietäre Betriebssystem freigegeben worden ist, und nur solche Kanäle und Eingabe/Ausgabebefehle benutzen kann, die spezifisch durch das proprietäre Betriebssystem zugewiesen worden sind. Anders ausgedrückt, es sind Mechanismen vorgesehen, um die beabsichtigte oder unbeabsichtigte Verwendung von Ressourcen zu verhindern, welche nicht der bestimmten Zentralverarbeitungseinheit- und Betriebssystemkombination zugewiesen sind.
Das obige System ist offenbart US-Patent Nr. 5 027 271 und 5 230 065, erfunden durch John L Curley, et al., mit dem Titel "Apparatus and Method for Alterable Resource Partitioning Enforcement in a Data Processing System Having Central Processing Units using Different Operating Systems" und "Apparatus and Method for a Data Processing System Having a Peer Relationship Among a Plurality of Central Processing Units", erteilt am 25. Juni 1991 bzw. 20. Juli 1993 und den dort genannten Inhabern zugewiesen. Es sei darauf hingewiesen, dass, während dieses System das Laufen von mehr als einem Betriebssystem ermöglicht, die Verwendung separater unabhängiger Zentralverarbeitungseinheiten und Mechanismen zum Erzwingen der Verwendung nur von zugewiesenen Systemressourcen benötigt.
Wenn verschiedene Betriebssysteme innerhalb eines Systems laufen, wird es wünschenswert, einen Nutzer mit der Fähigkeit des Nutzen beider Systeme in einer effizienten Weise zu versehen. Bei dem System des Standes der Technik von US-Patent Nr. 5 230 065 darf ein Nutzer auf beide Betriebssysteme zugreifen durch einen Nutzerregistrierungsprozess, der auf dem proprietären Betriebssystem durchgeführt wird, dessen Ergebnisse dann zu dem nicht-proprietären Betriebssystem transferiert werden. Wenn ein Nutzer auf dem proprietären Betriebssystem als zugriffhabend auf beide Systeme registriert worden ist, kann der Nutzer einen speziellen Schaltbefehl erteilen, der das Nutzerterminal auf das nicht-proprietäre Betriebssystem umschaltet. Der Schaltbefehl erlaubt permanenten Zugriff (d. h. Zugriff bis zum Logout von der gegenwärtigen Sitzung) oder temporären Zugriff (d. h. Zugriff, um einen einzelnen Befehl auszuführen) auf das nicht-proprietäre Betriebssystem. Während dieses Zugriffs ist der Nutzer fähig, Befehle zu erteilen, während dem Ablaufen auf dem nicht-proprietären Betriebssystem, welches z. B. den Transfer von Daten zu dem anderen Betriebssystem erlauben kann. Für eine weitere Beschreibung dieses Systems und der Arbeitsweise sei Bezug genommen auf die Veröffentlichung mit dem Titel "GCOS6 HVS6 PLUS XC Processor Systems Basics", veröffentlicht durch Bull HN Information Systems Inc., mit dem Datum Dezember 1991, Bestellnummer LH39-02.
Während die obige Anordnung des Standes der Technik es einem Nutzer erlaubt, auf beide Betriebssysteme zuzugreifen, findet ein derartiger Zugriff statt auf dem Nutzerniveau, während beide Betriebssysteme ihren unabhängigen Betriebsmodus aufrechterhalten. Es sei darauf hingewiesen, dass dieser Typ von Zugriffsfähigkeit nur aufgerufen werden kann bei einem hohen Niveau und noch Nutzerinteraktionen mit beiden Betriebssystemen als unabhängige Einheiten benötigt. Somit war diese Fähigkeit tatsächlich über beide Betriebssysteme aufgesetzt und verließ sich stark auf die Fähigkeit des Nutzers, die richtige Sequenz von Befehlen beider Systeme für die Ausführung der geeigneten Prozeduren durch jedes Betriebssystem einzugeben. Diese Anordnung ist weniger effizient, weil sie sehr schwerfällig und zeitraubend zu nutzen sein kann.
Des Weiteren ermöglicht die obige Anordnung des Standes der Technik keine stringente Sicherheitsdurchsetzung innerhalb beider Betriebssysteme. Das heißt das proprietäre Betriebssystem validiert Sicherheit hinsichtlich nicht autorisiertem Zugriff für das gesamte System durch den Login-Mechanismus des proprietären Betriebssystems. Hinsichtlich der Sicherheit zum Verhindern von Kompromittierungen in den Daten umfasst das System Mechanismen, welche das proprietäre Betriebssystem dazu befähigen, Restriktionen hinsichtlich Ressourcen auf dem nicht-proprietären System zu erzwingen. Somit wäre diese Art von Ansatz nicht effektiv in Systemen wie z. B. demjenigen der vorliegenden Erfindung in dem Fall, dass die Anwendungsprogramme, die auf dem proprietären Betriebssystem ablaufen, die Anwendungsprogramme sind, welche durch das Host-System zu emulieren sind.
Des Weiteren bei den Typ von betrachteten proprietären Betriebssystem des Standes der Technik sind Informationen, welche einen substanziellen Teil der Organisation des Betriebssystems offenbart, und dessen zugeordneter Datenstrukturen historisch zugänglich gemacht worden zu Nutzern. Daher ist es wahrscheinlich, dass ein wissender Nutzer absichtlich oder unabsichtlich die Betriebssystem- Datenstrukturen verändern könnte, welche die Identität und Datenzugriffsrechte des Nutzers definieren, um Zugriff zu anderen Nutzersystemdatendateien zu gelangen. Weil dieser Typ von Aktivität unerkannt in dem System des Standes der Technik verlaufen würde und daher nicht verhinderbar wäre, würde dies in signifikanten Kompromittierungen der Systemsicherheit resultieren.
Die Veröffentlichung Karger P. A. et al.: "A VMM Security Kernel for the VAX Architecture", Proceedings of the Symposium on Research in Security and Privacy Oakland, Z bis 9 Mai 1990, Nr. Symp. 11, 7 Mai 1990, Institute of Electrical and Electronics Engineers, Seiten 2-19 offenbart einen virtuellen Maschinenüberwachungs-(VMM)-Sicherheitskern für die VAX Architektur. Er unterstützt multiple gleichlaufende virtuelle Maschinen auf einem einzelnen VAX-System, Isolation und gesteuertes Teilen sensibler Daten bereitstellend. Zwei separate Befehlssätze sind vorgesehen für die Sicherheit, die SECURE-Befehle analysiert in den VMS- und ULTRIX-32-Betriebssystem und die SECURE-Server-Befehle. Alle Nutzer müssen bestimmte SECURE-Server-Befehle eingeben, um sich in virtuelle Maschinen einzuloggen und zu verbinden. Dann, auf Empfangen eines validen-Nutzer-SECURE-Befehls, instruiert die virtuelle Maschine den Nutzer, den SECURE-Befehl zu bestätigen durch manuelles Drücken einer Taste.
Demgemäß ist es ein primäres Ziel der vorliegenden Erfindung, Zugriff zu schaffen auf Host-Einrichtungen für effizientere Ausführungen von Anwendungsprogrammen, die auf einem Host-System emuliert werden.
Es ist ein weiteres Ziel der vorliegenden Erfindung, ein Verfahren und ein System bereitzustellen, welches Anwendungsprogramme, die in einer Emulationsumgebung auf einem Host-System ablaufen, ermöglicht, effizient in einer hochsicheren Weise ausgeführt zu werden.
Es ist ein weiteres Ziel der vorliegenden Erfindung, ein Verfahren und ein System bereitzustellen zum Ausführen von Anwendungsprogrammen, die in einer Emulationsumgebung ablaufen auf einem Host-System, welches keine Änderungen an den Host-System-Betriebssystem Einrichtungen benötigt, wodurch Software- Verbesserung und Unterstützung erleichtert wird.

Kurzfassung der Erfindung

Das obige und andere Ziele der vorliegenden Erfindung werden erreicht in einer bevorzugten Ausführungsform des Host-Datenverarbeitungssystems der vorliegenden Erfindung, welches eine Mehrzahl von Eingabe/Ausgabevorrichtungen umfasst und unter der Steuerung eines nicht-proprietären Betriebssystems arbeitet. In einer bevorzugten Ausführungsform ist das Betriebssystem eine verbesserte Version des UNIX-Betriebssystems, bekannt als das AIXTM-Betriebssystem, entwickelt durch IBM Corp. Das Host-System umfasst einen Emulator, der als ein Anwendungsprozess abläuft zum Ausführen von nutzeremulierter Systeme (Es)- Anwendungsprogrammen, welche in der bevorzugten Ausführungsform ursprünglich geschrieben worden sind zur Verwendung auf der DPS6- und DPS6000-Familie von Computern und den GCOS6TM- und HVS- Betriebssystemen, entwickelt durch Bull HN Information Systems Inc.
Der Emulator umfasst eine Anzahl von emulierten Systemausführungsdienstkomponenten (z. B. HVS-Ausführungsservicekomponenten), die in ES-Host-Systemgeteilter Speicherumgebung arbeiten und einen Interpreter, eine Emulatorüberwacher-Aufrufeinheit (EMCU) und eine Anzahl von Server-Einrichtungen, die in der Host-System-Speicherumgebung arbeiten. Die ES- Ausführungsdiensteinrichtungen sind erweitert und modifiziert, um eine Anzahl von Dualdekorbefehlen und Funktionen aufzunehmen, welche Host-System- Einrichtungen direkt verfügbar machen für ES-Anwendungsprogramme durch gleichzeitige Ausführung von Programmoperationen innerhalb sowohl der Emulator- als auch der Host-System-Umgebungen.
Die EMCU umfasst Mechanismen zum Durchführen einer Anfangsniveau- Sicherheitsvalidationsoperation, welche nachfolgende vertraute Verifizierung von Nutzeridentität erlaubt, wenn Dualdekorbefehle oder Funktionen aufgerufen werden. Die Server-Einrichtungen umfassen Mechanismen zum Durchführen eines Zweischritt-Sicherheitsvalidierungsprozesses zum Sicherstellen von Sicherheit hinsichtlich des Verhinderns sowohl unautorisierten Nutzerzugriffs und Kompromittierungen bei Nutzerdaten durch unsaubere Verwendung von Dualdekorbefehlen oder Funktionen. Der erste Schritt validiert Sicherheit auf dem Nutzerniveau und der zweite Schritt validiert Sicherheit auf dem Dateiniveau.
Genauer gesagt, validiert zuerst das System, dass der Nutzer, welcher die Operation aufruft, tatsächlich ein vertrauter Dualdekor-Nutzer ist. Dies wird ausgeführt durch Verwenden eines eindeutigen verschlüsselten Beschreibungseintrags jedes Dualdekor-Nutzers, der zuvor gespeichert wurde in einer Nutzertabelle, welche in der Host-Speicherumgebung platziert ist, welche für ES-Nutzer unzugänglich ist. Das Speichern des Eintrags wird durchgeführt als Teil der Login-Prozedur, in welcher das ES-System, auf Verifizieren, dass der Nutzer ein Dualdekor-Nutzer ist, einen speziellen Überwachungsaufruf an die EMCU ausgibt. Nach Validieren, dass der spezielle Überwachungsaufruf von der sauberen Quelle kam, verifiziert die EMCU, dass der Nutzer ein autorisierter Host-System-Nutzer ist durch die Host-verschlüsselten Passwort-Einrichtungen. Wenn die Nutzeridentität einmal authentifiziert worden ist, schafft das ES-System den geeigneten Eintrag in der Nutzertabelle, welcher die Persönlichkeit des Nutzers eindeutig definiert.
Gemäß der vorliegenden Erfindung hat dieser verschlüsselte Beschreibungseintrag drei Basisteile oder Komponenten. Diese sind: die emulierte Systemnutzer-ID selbst, welche, während der Login-Prozedur, dargestellt wurde als mit der Host- Nutzeridentifikation übereinstimmend; die Adresse einer ersten emulierten Systemdatenstruktur, welche die Stelle des Nutzersteuerblocks (UCB) und die Adresse einer zweiten emulierten Systemdatenstruktur, welche die Stelle des Gruppensteuerblocks (GCB) definiert. Die Adressen von jedem Satz dieser Datenstrukturen sind eindeutig zugewiesen zu einem Nutzer durch die geeignete ES- Systemkomponente während Login, und nur eine einzige Kopie für jeden gegebenen ES-Nutzer existiert im Speicher. Durch Aufrechterhalten dieses Satzes von eindeutig zugewiesenen Adressen dieser Datenstrukturen und Assoziieren derselben mit der Nutzer-ID, ist das System gemäß der vorliegenden Erfindung nun in der Lage, während des ersten Schritts der Verifizierung zu bestimmen, dass der Nutzer ein vertrauter Dualdekor-Nutzer ist an dem Punkt, wenn ein Dualdekorbefehl oder Funktion aufgerufen wird durch den Nutzer.
Die Nutzerpersönlichkeit wird validiert durch die EMCU, wobei sie bestätigt, dass der Nutzer ein vertrauter Dualdekor-Nutzer ist bei dem Punkt, wenn ein Dualdekorbefehl oder Funktion aufgerufen wird durch den Nutzer.
Die Nutzerpersönlichkeit wird validiert durch die EMCU, welche bestätigt, dass die ursprüngliche Beschreibung oder Persönlichkeit des Nutzers nicht geändert worden ist. Das heißt, der Nutzer hat die Nutzer-ID nicht geändert, so dass sie nicht länger zugeordnet ist mit demselben Satz von UCB- und GCB- ursprünglich zugewiesener Adressen, angebend, dass die Nutzerpersönlichkeit geändert worden ist.
Wenn die Nutzerbeschreibung als gültig aufgestellt ist, dann wird der geforderte Typ von Server-Einrichtungen erzeugt oder zugewiesen und notwendige Verbindungen werden gemacht zwischen den Server-Einrichtungen und der ES- Komponente, welche den Dualdekorbefehl oder Operation initiierte.
Wenn das System bestimmt, dass der Benutzer, welcher den Dualdekorbefehl oder die Funktion aufruft, nicht ein legitimer Dualdekor-Nutzer ist, unternimmt das System keine weitere Aktion (d. h. es baut nicht die nötigen Verbindungen auf), um den Dualdekorbefehl oder die Funktion auszuführen. Somit gibt es keinen Weg für den Nutzer, den Befehl oder die Funktion ausgeführt zu bekommen, was somit Sicherheit gewährleistet. Der Nutzer wird von der Verletzung durch die bestimmte ES-Komponente, welche die Operation initiierte, benachrichtigt.
Der zweite Schritt wird durchgeführt durch die Server-Einrichtungen auf dem Datei- oder Verzeichnisniveau bei der Dateizugriffszeit (geöffnet) unter Verwendung des eingebauten Dateischützmechanismus des Host-Systems, um die Nutzerzulassungen zu vergleichen innerhalb der Gruppe, zu welchen der Nutzer gehört, mit den Zulassungen, welche den Datendateien, die zuzugreifen ist, zugewiesen sind, um zu verifizieren, dass sie korrekt sind. Wenn sie korrekt sind, darf die geforderte Operation voranschreiten. Wenn der Benutzer bestimmt wird als nicht das benötigte Niveau von Erlaubnis zu haben, dann führen die Server- Einrichtungen die geforderte Operation nicht durch und der Benutzer wird benachrichtigt von der Zugriffssicherheitsverletzung.
Bei der bevorzugten Ausführungsform führt ein dynamisches Server- Handhabungsmittel (DSH), enthalten als Teil der Server-Einrichtungen, den ersten Schritt der Sicherheitsvalidierungsoperation für im Wesentlichen alle der verschiedenen Typen von Dualdekorbefehlen und Funktionen durch. Der Zugriffsüberprüfungsschritt wird durchgeführt auf einem niedrigeren Niveau durch einen Server, zugewiesen oder erzeugt durch die DSH-Einheit, um die einzelne Dualdekoroperation durchzuführen. Zugriffssteuerüberprüfung wird ausgeführt auf einem niedrigeren Niveau, wo sie ausgeführt werden kann durch den spezifischen Typ von Server, der dazu bestimmt ist, diese Operation zu handhaben, und für effektivere Validierung jedes Typs von Dualdekor-Dateizugriffsanforderungen (z. B. Öffnen, Lesen, Schreiben). Zum Beispiel gewährleistet diese Anordnung Sicherheit in solchen Situationen, wo es nicht möglich ist, den Typ von Zugriff, der durch einen bestimmten Benutzer angefordert wird, zu bestimmen, bevor eine anfängliche Phase der Operation stattfinden darf.
Gemäß den Lehren der vorliegenden Erfindung wird eine Anzahl von verschiedenen Typen von Dualdekorbefehlen oder Funktionen bereitgestellt als Teil der Dualdekoreinrichtungen. Dualdekorbefehle und Funktionen werden in zwei Weisen bestimmt. Sie werden bestimmt in der Form von neuen Befehlen oder als Erweiterungen zu bestehenden Befehlen wie z. B. durch das Einschließen einzigartiger designierter Argumente, welche Host-Systemeinheiten bestimmen (z. B. Host-Pfad oder Prozedurnamen).
Die Dualdekorbefehle und Funktionen erlauben es einem emulierten Systemnutzer, Ausführung ihrer emulierter Systemsanwendungsprogramme zu erweitern mit Host-Anwendungsprogrammen und Mechanismen. Die vorliegende Erfindung schafft diese Fähigkeiten durch die Integration von Dualdekorfunktionalität innerhalb der Emulationseinrichtung, was bestimmte Operationen einfacher durchzuführen macht unter Verwendung einzelner oder Kombinationen von Dualdekorbefehlen.
Zum Beispiel kann ein Dualdekorbefehl, bekannt als ein XShell-Befehl, verwendet werden, um eine existierende Anwendung zu ersetzen, wie z. B. eine Office- Automatisierungsanwendung mit einer äquivalenten Host-Anwendung. Andere Dualdekorbefehle können verwendet werden, um Vorteil zu ziehen aus den Host- Datei und Datentransfermechanismen. Zum Beispiel kann ein Nutzer einen Befehl verwenden, der bekannt ist als ein CopyX-Befehl, um Datei in das ES-System auf das Host-System zu bewegen, wo sie transferiert werden können zu einem anderen System über die Host-System-Dateitransfereinrichtung (FTP), welche durch einen XShell-Befehl aufgerufen werden kann.
Zusätzlich können dann Dualdekorbefehle verwendet werden, um Operationen auf Dateien, welche in beiden Systemen angeordnet sind, während derselben Sitzung durch Zuführen. Auch können Dualdekorbefehle verwendet werden, um Operationen auf einer Datei durchzuführen, die zuvor gepflegt wurde durch ES-System, welches nun durch das Host-System gepflegt wird (z. B. eine Dump-Datei). Ein Dualdekorbefehl, bekannt als ein Link-Datei-Befehl, kann verwendet werden, um Verzeichnisdateien zusammenzulinken, die in beiden System angeordnet sind, so dass ein gegebenes ES-Programm wie z. B. ein Editor, verwendet werden kann, um Dateien auf beiden Systemen während derselben Sitzung zu editieren. Eine weitere Form desselben Befehls kann verwendet werden, um es zu ermöglichen, dass Programme innerhalb der beiden Systeme kooperativ zusammen arbeiten, um eine gegebene Operation auszuführen. Zum Beispiel kann eine Link-Pipe-Version des Befehls verwendet werden, um Host-Name-Pipe-Einrichtungen bereitzustellen, um zuzulassen, dass die Ausgabedaten von einem ES-Programm verwendet werden als die Eingabe zu einem Host-Programm oder umgekehrt, während beide Programme durch ihre jeweiligen Systeme ausgeführt werden. Dieses sind einige der grundlegenden Eigenschaften und Vorteile, die durch die bevorzugte Ausführungsform der vorliegenden Erfindung bereitgestellt werden. Diese Eigenschaften und Funktionen erlauben es Nutzern, den Übergang vorzunehmen von einer emulierten Systemumgebung auf ein Host-System in ihrer eigenen Gangart. Für weitere Informationen hinsichtlich dieser Befehle kann Bezug genommen werden auf die referenzierten verwandten gleichzeitig anhängenden Patentanmeldungen.
Die obigen Ziele und Vorteile der vorliegenden Erfindung werden besser verstanden weiden von der folgenden Beschreibung, wenn sie in Verbindung mit den beigefügten Zeichnungen genommen wird.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm eines Host-Systems, welches die Dualdekorfunktionalität gemäß den Lehren der vorliegenden Erfindung inkorporiert.
Fig. 2a-3b sind Flussdiagramme, die verwendet werden im Beschreiben der Operation der vorliegenden Erfindung.

Beschreibung der bevorzugten Ausführungsform

Fig. 1 ist ein Blockdiagramm eines Host-Systems 54, welches die Dualdekorkomponenten der vorliegenden Erfindung inkorporiert. Wie gezeigt ist, umfasst das System 54 eine Hardware-Plattform 56, welche die Hardware-Elemente umfasst wie z. B. eine Zentralverarbeitungseinheit 58a, ein Hauptspeicher 58b und eine Anzahl von Eingabe/Ausgabe-Peripherer/Kommunikationseinrichtungen inklusive einen lokalen Bereichsnetzwerk zum Verbinden des Systems 54 mit weiteren Verarbeitungssystemen über Standardkommunikations-Netzwerkeinrichtungen.
Die Zentralverarbeitungseinheit (CPU), repräsentiert durch Block 58a, ist eine Reduced-Instruktionset (RISC)-basierte Verarbeitungseinheit, welche die Form des RS6000-Mikroprozessors einnimmt, hergestellt durch IBM Corp. Die Hardware-Plattform 56 kann auch die Form des DPX/20-Systems annehmen, auf den Markt gebracht durch die Bull HN Information Systems Inc.
Wie in Fig. 1 gesehen werden kann, arbeitet die Hardware-Plattform mit Verarbeitungseinheit 58a unter der Steuerung einer verbesserten Version des UNIXTM- Betriebssystems, wie z. B. des AIXTM-Betriebssystems. Teile von physikalischem Speicher, repräsentiert durch MEM-Block 58b, sind illustriert in Bezeichnungen des geschichteten Aufbaus. Wie gezeigt ist, ist der Speicher geteilt in zwei Basisniveaus, einem Nutzerniveau und einem Betriebssystemniveau. Das Nutzerniveau ist geteilt in einen emulierten System (ES)- und Host-geteilten Speicherbereich und Host- oder einem nativen Betriebssystemkern-Speicherbereich. Der geteilte Speicherbereich enthält das ES-Ausführungsniveau 16, welches eine Mehrzahl von Ausführungsprogrammtasks 30 umfasst, welche durch ES- Ausführungsdienstkomponenten des Blocks 28 erzeugt wurden zum Ausführen von ES-Anwendungsprogrammen 22 und Systemadministratorprogrammen 24.
In dem emulierten System verwendet jeder Task 30 eine Mehrzahl von Datensteuerstrukturen, wie z. B. eine Task-Steuerblock-(TCB)-Struktur 32, eine indirekte Anforderungsblock-(IRB)-Struktur 36, eine Eingabe/Ausgabeanforderungsblock-(IORB)-Struktur 38 und eine Ressourcen- Steuertabelle-(RCT)-Struktur 40. Die Task-Steuerblock-(TCB)-Struktur 32 umfasst Information bezüglich des Zustands der Ausführung des assoziierten Task ebenso wie Zeiger auf unterbrechungssichere Bereiche zum Speichern von Hardware-Parametern, bezogen auf den Task. Die indirekte Anforderungsblock-(IRB)- Struktur 36 umfasst Information, welche die Operation definiert, welche durch einen zugeordneten Task angeforderten wird, und umfasst Zeiger, welche den Task identifizieren, und seinen assoziierten Task-Steuerblock (TCB) und einen Zeiger auf die assoziierte IORB-Struktur.
Die Eingabe/Ausgabeanforderungsblock-(IORB)-Struktur 38 wird verwendet als das Standardmittel zum Anfordern eines physikalischen I/O-Dienstes. Sie umfasst Informationen wie z. B. eine logische Ressourcennummer (LRN) welche die I/O- Vorrichtung identifiziert, welche adressiert wird, ebenso wie die Stelle und Größe des Puffers, der zu verwenden ist für den Transfer und die angeforderte spezifische Funktion (Operation). Die Ressourcensteuertabelle-(RCT)-Struktur 40 umfasst Information, welche die Ressourcen beschreibt, wie z. B. ihre Eigenschaften oder Information hinsichtlich der Tasks oder Anforderungen, welche ausgeführt werden durch eine entsprechende Ressource ebenso wie Zeiger auf ihre assoziierte Task-Steuerblock-(TCB)-Struktur.
Zusätzlich sind zwei weitere Strukturen, dargestellt in Fig. 1, verwendet durch die vorliegende Erfindung, eine Gruppensteuerblock-(GCB)-Struktur und eine Nutzersteuerblockstruktur von Block 29. Die GCB-Struktur umfasst Information, die erforderlich ist, um die Operationen einer spezifischen Taskgruppe zu definieren und zu steuern, welche einen benannten Satz von einem oder mehrer Tasks definiert mit einem gemeinsamen Satz von Ressourcen, innerhalb welcher ein Nutzer und Systemfunktion arbeiten müssen. Jede Gruppe hat einen Zwei-Zeichen- Namen (z. B. $L, $S), durch welchen die Gruppe dem System eindeutig bekannt ist. Die GCB-Struktur umfasst Information, welche den führenden Task identifiziert, dessen Ausführungen alle weiteren Tasks erzeugt, die erforderlich sind zum Ausführen der Gruppenprogramme. Wie angedeutet, umfasst die GCB-Struktur eine Anzahl von Nutzersteuerblöcken (UCB), deren jeder Informationen umfasst, welche die Persönlichkeit des Nutzers definiert, wie z. B. Nutzerknotenidentifikation, Nutzergruppen-ID innerhalb eines Knotens, Nutzertask-ID innerhalb der Gruppe, Nutzerperson-ID und Zeigerinformation auf Verzeichnisse, auf welche der Nutzer Zugriff hat.
Wie gezeigt ist verwendet das emulierte System eine weitere Datenstruktur entsprechend der Systemsteuerblock-(SCB)-Struktur 27. Diese Datenstruktur wird erzeugt beim Systemstart und umfasst Information, welche Systemressourcen und Zeiger auf die verschiedenen Taskgruppen definiert, die durch das System aufgebaut werden, dargestellt durch eine entsprechende Anzahl von Gruppensteuerblöcken in dem System. Für weitere Informationen hinsichtlich derartiger Strukturen und deren Beziehungen zueinander kann Bezug genommen werden auf US-Patent Nr. 5 111 384 und die Veröffentlichung mit dem Titel "HVS PLUS Systems Concepts", veröffentlicht durch Bull HN Information Systems Inc., Bestellnummer HE03-01.
Wie in Fig. 1 angegeben ist, umfasst der geteilte Speicherraum des Weiteren eine Speicher-Warteschlangen-Schnittstelle (MQI), dargestellt durch Block 84, welche eine Form von Interprozess-Kommunikationsmechanismus schafft, und eine Software-Aktiv-Warteschlange (SAQ) von Block 88. SAQ-Block 88 repräsentiert eine Datenstruktur, die verwendet wird, um den Pfad bereitzustellen, über welchen die Ergebnisse der Operationen, durchgeführt durch Kernelniveaukomponenten, zurückgeführt oder zurückgegeben werden durch die Host-Prozesse an die anfordernden emulierten Systemnutzerniveautasks 30, die gerade ausgeführt werden. Somit kann er betrachtet werden als funktionierend als eine Ausgabestufe von MQI 84. Diese Datenstruktur ist ähnlich zu den Datenstrukturen, welche verwendet werden durch das emulierte System-Betriebssystem.
MQI-Block 84 ist eine Semaphore-Datenstruktur, welche die Form einer einzelnen verlinkten Liste annimmt, gesteuert durch Semaphoren durch einen Satz von Routinen, welche ausgeführt werden durch die verschiedenartigen Host-Prozesse, die innerhalb verschiedener Niveaus oder Schichten arbeiten, welche miteinander kommunizieren möchten. Seine Routinen werden verwendet, um Warteschlangen innerhalb der Pseudo-Vorrichtungstreiber 74 und der Software-Aktiv- Warteschlange 88 zu verwalten.

Ausführungsdienstkomponenten 28

Wie in Fig. 1 gesehen werden kann, umfassen die Ausführungsdienstkomponenten 28 der Ausführungsschicht 16 eine Mehrzahl von Komponenten oder Einrichtungen, die äquivalent zu denjenigen Einrichtungen sind die normalerweise in einem emulierten System enthalten sind. Die Einrichtungen, die durch die vorliegende Erfindung verwendet werden, umfassen ein Listenermodul 280, eine Dateiverwaltungseinrichtung 282, eine Überwachungsaufrufeinheit 284 und eine ES- Handhabungseinheit 286, welche angeordnet sind wie gezeigt ist. Das Listenermodul 280 ist verantwortlich für das Überwachen der Operationen der Terminals, die konfiguriert sind für Login und für den Beginn von Nutzer-Tasks in Antwort auf Nutzerbefehle. Wie in Fig. 1 angegeben ist, läuft Listenermodul 280 als ein Task 30 mit seinem eigenen Satz von eindeutigen Datenstrukturen ab.
Wie hier beschrieben ist, ist das Listenermodul 280 in der Lage, eine Profildatei zu konsultieren, welche nutzerspezifische Registrierungsinformation umfasst, wie z. B. Nutzer-ID, Login-ID und Passwort-Anforderungen, die durch den Systemadministrator für alle registrierten Nutzer tabuliert sind. Das Listenermodul 280 überprüft das Nutzerprofil beim Überwachen der Privilegien und/oder Restriktionen, die jedem Nutzer gegebenen sind. Die Dateiverwaltungseinrichtung 282 umfasst die herkömmlich geteilte Datenstruktur und den Satz von Routinen, die normalerweise bereitgestellt werden, um Funktionen durchzuführen, welche auf eine derartige Datenstruktur zugreifen, um die Synchronisierung gleichzeitig verlaufender Prozesse oder Tasks zu steuern zusätzlich zum Durchführen verschiedenartiger Systemdienste oder Funktionen. Das heißt die Einrichtung antwortet auf Systemdienstüberwachungsaufrufe, welche die Typen von angeforderten Diensten identifizieren (z. B. Erzeugen oder Zerstören von Dateien, Lesen oder Schreiben von Datensätzen oder Blöcken in Dateien), was darin resultiert, dass die spezifizierten Systemdienste ausgeführt werden durch das emulierte System für das Ausführen von Nutzeranwendungsprogrammen.
Die Überwachungsaufrufeinheit 284 empfängt Überwachungsaufrufe von der Interpreterkomponente 72, welche ihrerseits interpretativ auszuführen sind unter Verwendung der ES-Ausführungsdienstkomponenten von Block 28. Die Befehlshandhabungseinheit 286 umfasst die Routinen, welche auf Nutzerbefehle antworten, die über ein Terminal oder Programm eingegeben werden. In Antwort auf derartige Befehle rufen die Routinen der Einheit 286 die geeigneten Tasks zum Ausführen derartige Befehle auf. Wie hier detaillierter diskutiert ist, sind jede dieser Komponenten erhöht oder erweitert worden, um verschiedene Dualdekoraspekte oder Eigenschaften gemäß den Lehren der vorliegenden Erfindung zu inkorporieren.

Emulatorniveauschicht 68

Wie in Fig. 1 angedeutet ist, ist die nächste Schicht innerhalb des Nutzerniveaus das Emulatorausführungsniveau 68. Dieses Niveau umfasst bestimmte Komponenten, die in den emulierten System präsent sind, welche in neue Mechanismen transformiert worden sind, die den übrigen unveränderten Komponenten so erscheinen, dass sie wie die originalen unveränderten Komponenten des emulierten Systems arbeiten. Zu derselben Zeit erscheinen diese neuen Mechanismen den Komponenten des Kernelniveaus 64 als native Komponenten, mit welchen das Host-System gewöhnt ist zu arbeiten. Wie gezeigt ist, umfassen die Komponenten den Interpreten 72, eine Emulatormonitoraufrufeinheit (EMCU) 73, eine Mehrzahl von Servern 90 bis 940, und eine Mehrzahl von Pseudogerätetreibern (PSDD) 74, die angeordnet sind wie gezeigt.
Zusätzlich umfasst Niveau 68 eine Datenstruktur in der Form von Nutzertabelle 96, welche Einträge umfasst, die eindeutig die Persönlichkeiten der verschiedenen Dualdekornutzer definieren. Diese Tabelle wird gepflegt, um in der Lage zu sein zu entscheiden, dass ein gegebener Nutzer erfolgreich durch die Login-Prozedur hindurchgegangen ist. Gemäß der vorliegenden Erfindung hat jeder derartige verschlüsselte Nutzerbeschreibungseintrag drei Basisteile oder Komponenten. Diese sind: die emulierte Systemnutzer-ID selbst, welche während der Login-Prozedur als mit der Host-Nutzer-Identifikation übereinstimmend ermittelt wurde; die Adresse einer ersten emulierten Datenstruktur, welche die Stelle des Nutzersteuerblock (UCB) definiert, und die Adresse einer zweiten emulierten Systemdatenstruktur, welche die Stelle des Nutzergruppensteuerblocks (GCB) definiert. Der Anhang zeigt das Format dieser Einträge detaillierter.
Der Interpreter 72 nimmt nacheinander die Instruktionen eines emulierten Systenanwendungsprogramms, kategorisiert jede Instruktion und führt sie interpretativ aus durch Sequenzen von RISC-Instruktionen, welche es CPU 58a, MEM 58b und anderen Elementen von Host-System 54 erlauben, die Operationen entsprechender Elemente des emulierten System zu emulieren. Der Interpreter 72 umfasst eine Überwachungsaufruf-(MCL)-Tabelle, welche Information umfasst für jeden möglichen Überwachungsaufruf, welchen er verwendet, um zu bestimmen, ob ein ES-Überwachungsaufruf einzufangen ist oder ein ES-Überwachungsaufruf zu senden ist an die ES-Ausführungsdienstkomponenten 28 zur Ausführung der Instruktion oder ein Emulatoraufruf an EMCU 83 vorzunehmen ist zur Ausführung der Instruktion durch die Dienste einer geeigneten C-Sprachenroutine (Server). Die EMCU 73 ist verantwortlich zum Annehmen von dem Host-System 54 des nötigen Speichers und weiterer Ressourcen, zum Initialisieren der emulierten Systemdatenstrukturen und Aufrufen von Interpreter 72 und den verschiedenartigen Server-Prozessen. Sowohl Interpreter 72 als auch EMCU 73 laufen als Host- Prozesse, jedoch nicht als Root.
Wie durch das Host-System gesehen, werden die ES-Dienstkomponenten 28 und Tasks 30, die seitens der Anwendungsprogramme ausgeführt werden, der Interpreter 72 und EMCU 73 ausgeführt in dem System 54 der Fig. 1 als ein einzelner Prozess 80, wobei ein derartiger Prozess einem oder mehreren Nutzerprozessen entspricht, wie definiert durch die Konventionen des Host-Betriebssystems, welches auf Host-System 54 abläuft. Somit ist es möglich, multiple Instanzen des emulierten Systems gleichzeitig auf Host-System 54 emuliert zu haben.
Der Passwort-Server 90, der dynamische Server-Handler (DSH) 92 und der Netzwerkterminaldriver (NTD)-Server 94 werden kreiert durch EMCU 73 während der Initialisierung. Jeder der Server 90, 92 und 94 kommuniziert mit emulierteren Systemprozessen durch MQI 84 wie angedeutet. Die tiefere Niveaugruppe von Server 920, 922 und 940 wird dynamisch kreiert durch ihre jeweiligen höheren Niveau-Server 92 und 94 zum Aufführen von Dualdekoroperationen gemäß der vorliegenden Erfindung. Alle Server arbeiten als Root und haben daher Super-User-Privilegien mit Zugriff auf jegliche Dateien innerhalb des Host- Systems 54. Der NTD-Server 94 ist dazu entworfen, die Funktionalität zu umfassen, die erforderlich ist, um verschiedene Typen von Endgeräten zu handhaben, wie z. B. der Netzwerkendgerätbetreiber, der beschrieben ist in US-Patent Nr. 4 951 245, welches erteilt ist am 21. August 1990.
Wie im Detail hier beschrieben ist, umfassen beide Server 92 und 94 Mechanismen, die spezifisch entworfen sind zum Validieren von Sicherheit auf dem Nutzerniveau in Verbindung mit der Ausführung von Dualdekorbefehlen und Funktionen. Wie in Fig. 1 gezeigt ist, umfasst die tiefere Niveau-Gruppe von Server 920, 922 und 940 jeder Zugriffsteuermechanismen, die verwendet werden, um Sicherheit auf dem Dateiniveau zu validieren. In dem Fall von Server 940 werden Zugriffsteuermechanismen verwendet.
Wie in Fig. 1 angedeutet ist, haben die EMCU 73, der dynamische Serverhandhaber 92 und NTD-Server 94 jeder Zugriff auf eine Datenstruktur in der Form einer Nutzertabelle (USRTBL) 96, welche angeordnet worden ist in dem Host-Raum, um unzugänglich zu sein für ES-Nutzeranwendungsprogramme. Wie hier detaillierter beschrieben ist, umfasst die Tabelle 96 verschlüsselte Nutzerdeskriptor information, welche verwendet wird zum Validieren der Identität eines Nutzers gemäß den Lehren der vorliegenden Erfindung. Die Verschlüsselung stellt Sicherheit im Fall eines Speichers-Dump sicher.
Wie in Fig. 1 angegeben, umfasst das Emulator-Ausführungsniveau 68 weiter eine Mehrzahl von Pseudo-Vorrichtungstreibern (PSDD) 74 für jede Eingabe/Ausgabevorrichtung oder Typ von Eingabe/Ausgabevorrichtung, welche durch Host-System 54 emuliert werden soll. Zum Beispiel werden die Pseudo- Vorrichtungstreiber 74 PSDDs für Terminals, Plattentreiber, Bandtreiber, Anzeigen und für bestimmte Kommunikationsvorrichtungen umfasst.
Für eine detaillierte Diskussion weiterer Aspekte von SAQ 88, MQI-Block 84, PSDD 74 und weiterer Emulatorkomponenten kann auf die verwandte Patentanmeldung Bezug genommen werden.

Betriebssystem/Kernelniveau

Das Betriebssystem/Kernelniveau 64 umfasst die Standardmechanismen und Komponenten, die normalerweise innerhalb des Host-Betriebssystems enthalten sind. Wie gezeigt, umfasst Niveau 64 eine Kernelprozessverwaltungskomponente 70, eine Host-Nutzer-Passwortdatei 700, eine Host-Verschlüsselungspasswort- Diensteinrichtung 702, Inode-Zulassungsdateienspeicher 704 und eine Anzahl von Host-Kernel-I/O-Dienste-(KIOS)-Prozesse 66 für jeden Pseudo-Gerätedriver (PSDD) 74, der zu emulieren ist durch das Host-System und für jeden der Server 920 bis 940 zugewiesen ist, um Dualdekorbefehle und Funktionen auszuführen. Weil die Komponenten des Kernel-Niveaus 64 wohl bekannt sind werden sie hier nur kurz beschrieben. Die Host-Nutzerpasswortdatei 700 wird verwendet zum Speichern von Information, welche registrierte Host-Nutzer identifiziert. Diese Datei wird aktualisiert und gepflegt durch den Host-Betriebssystem- Kernelprozessverwalter 70. Ein Teil der Information, die in der Passwortdatei 700 gespeichert ist, ist das Nutzer-verschlüsselte Passwort, welches erzeugt wird unter Verwendung der Einweg-Passwortdiensteinrichtung 702, die durch den Kernelprozessverwalter 70 aufgerufen wird.
Der Inode-Zulassungsdateienspeicher enthält Einträge, welche die Attribute und Plattenadressen jeder Datei in dem System auflisten. Jeder Inode-Eintrag umfasst Information bezüglich des Typs, der Größe, Zeiten, Inhaberschaft und Plattenblöcke in jeden Inode. Die Verzeichnisstruktur in dem Host-System verwendet Einträge, deren jeder gerade einen Dateinamen und seine Inode-Zahl enthält. Die Attribute eines Eintrags umfassen Referenzen, um auf Steuerlisten (ACLs) zuzugreifen, welche die Basis der Datei und jedwede erweiterte Zulassung definieren. Die Basiszulassungen entsprechen den herkömmlichen Dateizugriffsmodi (d. h. Lesen, Schreiben und Ausführen/Suchen), die einen Dateiinhaber, einer Dateigruppe und anderen Nutzern zu gewiesen sind. Die erweiterten Zulassungen bestimmen, wie die Basiszulassungen modifiziert worden sind hinsichtlichen Zulassen, Verweigern oder Spezifizieren von Zugriffsmodi für bestimmten Individuen, Gruppen oder Nutzer und Gruppenkombinationen, bestimmt durch Nutzer und Gruppen- IDs. Zum Zweck der vorliegenden Erfindung kann diese Anordnung betrachtet werden als herkömmlich im Entwurf.
Zusätzlich, in dem bevorzugten Beispiel des Host-Systems 54 wird angenommen, dass das Niveau 64 die Standardutility-Programme, Shell, Editoren, Compiler, usw. sowie Bibliotheken (z. B. I/O-Bibliotheken, Öffnen, Schließen) enthält, auf welche in dem Host-Nutzermodus zu gegriffen wird. Für weitere Informationen hinsichtlich der Verwendung derartiger Anordnungen kann Bezug genommen auf Publikationen der IBM Corp., welche das AIX-Betriebssystem beschreibt.

Beschreibung des Betriebs

Unter Bezugnahme auf die Flussdiagramme 2a bis 3b werden nunmehr der Satz von Dualdekorbefehlen und Funktionen, die in das System 54 inkorporiert sind, gemäß den Lehren der vorliegenden Erfindung beschrieben werden. Wie diagrammartig in Fig. 1 illustriert ist, umfassen Dualdekorbefehle und Funktionen neue Befehle und Erweiterungen zu existierenden Befehlen des emulierten Systembefehlsatzes. Die Befehle umfassen einen Dateikopierbefehl (CPX), einen Shell-Befehl (XSH) und eine verbesserte Version eines emulierten Systemlinkbefehls (LK).
Der CPX-Befehl schafft die Fähigkeit, eine Datei in jeder Richtung zwischen dem emulierten System und dem Host-System zu kopieren oder transferieren. Der XSH-Befehl schafft die Fähigkeit, Host-Prozeduren zu aktivieren und deaktivieren durch Host-Systemeinrichtungen durch die Ausführung von synchronen und asynchronen Shell-Befehlen. Der LK-Befehl schafft die Fähigkeit für emulierte Systemanwendungsprogramme mit Zugriff auf verschiedene Typen von Host- Dateien. Diese umfassen Textdateien und Host-benannte Pipes, auf die zugegriffen wird, um Interprozesskommunikationen zu schaffen zwischen gleichzeitig ausgeführten emulierten und Host-Systemanwendungsprogrammen zum Erlauben von kooperativem Verarbeiten.
Die Formate dieser Befehle sind dargelegt in dem Anhang und sind auch beschrieben im Detail in den referenzierten bezognen Patentanmeldungen. Es wird erkannt werden von dem Anhang, dass verbesserte oder erweiterte emulierte Systembefehle, wie z. B. der verschiedene Typ von LK-Befehlen jeder eine vorbestimmt Variable benutzt wie z. B. ein großes x, welches von einem: (d. h. "X:) gefolgt wird, um seine Dualdekoraspekte zu bezeichnen.
Wie bezeichnet durch die schattierten Kästen in Fig. 1 sind die verschiedenen Komponenten von Block 28 erweitert worden, um den Satz von Dualdekorbefehlen und Funktionen aufzunehmen. Das Listenermodul 280 ist erweitert worden, um eine Validierungsroutine zu inkorporieren, welche aufgerufen wird, wenn ein Nutzer sich auf das emulierte System einloggt. Dies veranlasst die Operationen von Fig. 2a, ausgeführt zu werden während des ES-Nutzerloggins.

Logon-Prozedur

Unter Bezugnahme auf Fig. 2a kann gesehen werden, dass das Listenermodul 280 zunächst den Nutzer auffordert, seinen oder ihren Namen (d. h. Nutzer-ID) einzugeben wie in dem Fall einer Standardsystem-Loginprozedur (Block 200). Als nächstes schaut das Listenermodul 280 beim Empfang der Nutzer-ID in dem emulierten Systemnutzerprofil nach, um zu verifizieren, ob der Nutzer ein Dualdekornutzer ist (Block 202). Spezifischer ausgedrückt, unterhält das emulierte System wie andere Systeme einen Nutzerprofildatensatz für jeden autorisierten Nutzer des Systems für Sicherheits- und Kontozwecke. Der Nutzerprofildatensatz umfasst normalerweise Informationen wie z. B. die Nutzer-ID, Zugriffsrestriktionen, Typ von Endgerät, usw. Als Teil derartiger Zugriffsrestriktionen umfasst der Profildatensatz ein besonderes Feld, welches kodiert ist zum Angeben, ob der Nutzer ein Dualdekornutzer ist. Wenn das Feld gesetzt ist auf einen vorbestimmten Wert (d. h. eine binäre 1), bedeutet dies, dass der Nutzer autorisiert ist, Dualdekorbefehle und Funktionen auszuführen.
Wenn das Listenermodul 280 feststellt, dass der Nutzer ein Dualdekornutzer ist (Block 204), unternimmt es die geeignete Aktion, um zu valideren, dass der Nutzer ein autorisierter Dualdekornutzer ist, was erfordert, dass der Nutzer registriert ist auf dem Host-System als ein autorisierter Host-Systemnutzer durch den Systemadministrator. Dies erfordert, dass der ES-Nutzer sich einloggt, um denselben Loginnamen (User_ID) wie der Host-Systemlogginname zu haben. Diese Anforderung wird ausgeführt durch Validieren der User_ID wie hier beschrieben ist. Wie in Fig. 2a angegeben ist, wird zunächst versucht, die User_ID zu validieren mit einem Null-Passwort (Blöcke 206 und 208). Das heißt, Listenermodul 280 gibt einen speziellen Überwachungsaufruf (MCL 3721-0), begleitet mit einem Null-Passwort aus. Um enge Sicherheit zu gewährleisten, kann dieser Typ von Überwachungsaufruf nur ausgegeben werden durch Listenermodul 280. Der Begriff Validieren, wie er hier benutzt wird, bezieht sich auf Aufrufen der Verschlüsselung des Passworts-Strings und Vergleichen der Ausgabe der Verschlüsselungspasswortdiensteinheit 702 gemäß dem verschlüsselten Passwort-String mit dem Host-Nutzereintrag, der erhalten wird von der Host-Nutzerpasswortdatei 700.
Der spezielle Überwachungsaufruf wird empfangen durch EMCU 73, welche erweitert worden ist durch zusätzliche Routinen, wie durch den schattierten Block bezeichnet ist, um die geforderte Validierungsoperation durchzuführen. Dies wird durchgeführt durch Passwort-Server 90, der eine Serie von Systemaufrufen an den Host-Betriebssystem-Kernel durchführt. Bevor jedoch dieses durchgeführt wird, führt, als Teil des Überwachungsaufrufs, die EMCU 73 eine Serie von Überprüfungen durch, um zu authentifizieren, dass der Aufruf tatsächlich ausgegeben worden ist durch Listenermodul 280 und nicht durch einen Imitator. Dies umfasst das Überprüfen, dass das Listenermodul 280 im Ring 0 läuft (d. h. das höchste Privileg hat) zusätzlich zu anderen Arten von Überprüfungen wie z. B. das Überprüfen seiner Gruppen-ID. Das heißt, weil das Listenermodul 280 als ein Task innerhalb des emulierten Systems läuft, hat es seinen eigenen eindeutigen Satz von GCB- und UCB-Datenstrutkuren, welche verwendet werden können beim Durchführen derartiger Überprüfungen. In dieser Weise stellt das System sicher, dass es einen vertrauenswürdigen Pfad zu dem Host-System gibt, durch welchen die Identität des Dualdekornutzers validiert werden kann.
Der spezielle Überwachungsaufruf des Listenermoduls 280 ruft den Passwort- Server 90 auf, der seinerseits das verschlüsselte ES-Nutzerpasswort erhält von der Host-Nutzerpasswortdatei 700. Auch veranlasst der spezielle Überwachungsaufruf EMCU 73, die Host-Verschlüsselungspasswortdiensteinheit 702 aufzurufen, um das Null-Passwort zu verschlüsseln und das verschlüsselte Null-Passwort mit dem ES-Passwort zu vergleichen. Wenn es keinen Vergleich gibt, dann wird kein Ergebnis zurückgegeben durch EMCU 73 an das Listenermodul 280. Wenn es einen Vergleich gibt, dann wird ein Ja-Ergebnis zurückgegeben an Listenermodul 280 durch EMCU 73.
Im Fall eines Vergleichs erzeugt EMCU 73 einen vorläufigen Nutzertabelleneintrag innerhalb der Nutzertabelle 96, welcher die Listenersteuerblockadresse umfasst. Auch inkrementiert es um 1 einen Dualdekortoken, der verwendet wird für korrektes Verfolgen von Lizenzen. Als nächstes, wie in Fig. 2b angedeutet ist, prüft das Listenermodul 280 das zurückgegebene Ergebnis (Block 210). Wenn die Antwort zurückkommt, dass das Null-Passwort valide war (Block 210 oder 220), dann muss der Nutzer nicht für ein Passwort aufgefordert werden. Wenn die Antwort zurückkam, dass das Null-Passwort nicht valide war, fordert das Listenermodul 280 dann den Nutzer für sein oder ihr Passwort auf (Block 214). So dann gibt das Listenermodul 280 den speziellen Überwachungsaufruf wieder aus zusammen mit dem vom Nutzer eingegebenen Passwort, um zu entscheiden, ob dieses Passwort valide ist (Block 216).
Wie in Fig. 2b angedeutet ist, werden die Operationen von Block 208 wiederholt (Block 218) und Listenermodul 280 überprüft wiederum das Ergebnis (Block 220). Das heißt das Passwort, das durch den Nutzer eingegeben worden ist, wird verschlüsselt und die verschlüsselte Ausgabe wird verglichen mit dem Host- Passwortdateieintrag für den ES-Nutzer, erhalten durch den Passwort-Server 90. Wenn die Antwort ist, dass das Nutzer-Passwort nicht valide war, dann fordert das Listenermodul 280 den Nutzer wieder auf nach einem anderen Passwort und gibt den speziellen Überwachungsaufruf noch mal aus. Diese Sequenz wird drei Mal wiederholt (Block 222). Wenn die Antwort immer noch die gleiche ist nach dem dritten Versuch, bricht das Listenermodul 280 die Prozedur ab und kehrt zum Beginn der Login-Sequenz zurück.
Wenn die Antwort zurückkam, dass das Passwort valide war, erzeugt das Listenermodul 280 die emulierte Systemtaskgruppe und ihre assoziierten GCB- und UCB-Strukturen äquivalent zu den GCB- und UCB-Strukturen von Block 29 in Fig. 1 (Block 224). Als nächstes verifiziert das Listenermodul 280, dass die Erzeuger-Gruppe-Anforderung nicht scheiterte (d. h. die Gruppe wurde erfolgreich geschaffen durch die emulierten Systemkomponenten) (Block 226).
Wenn aus irgendeinem Grund die Gruppe nicht erfolgreich erzeugt werden konnte (z. B. nicht genügend Speicher für diesen Nutzer verfügbar war), wird dieses Ereignis detektiert und resultiert darin, dass das Listenermodul 280 einen anderen Typ des speziellen Überwachungsaufrufs (MCL 3721-2) an EMCU 73 ausgibt (Block 228). Dies resultiert darin, dass die EMCU 73 den vorläufigen Nutzertabelleneintrag innerhalb der Nutzertabelle 96 löscht zusätzlich zum Wiederherstellen des Dualdekortoken auf seinen vorherigen Wert (Block 230). Wie in Fig. 2c angedeutet ist wird diesen Operationen dadurch gefolgt, dass das Listenermodul 280 die unternommene Aktion an den Nutzer berichtet und einen emulierten Systemloginbanner ausgibt, gefolgt von einer Rückkehr zu dem Beginn der Login-Prozedur (Block 234).
Wenn das Listenermodul 280 verifiziert, dass die Gruppe erfolgreich geschaffen worden ist, dann gibt es einen anderen Typ eines speziellen Überwachungsbefehls (MCL 3721-1) an EMCU 73 aus (Block 232). Dies veranlasst EMCU 73 dazu, den vorläufigen Tabelleneintrag in der Nutzertabelle 96 entgültig zu machen, wobei die Adresse des GCB geändert wird von dem Listenermodul GCB auf diejenige des Nutzer-GCB (Block 236). Als nächstes vervollständigt das Listenermodul 280 die Nutzerlogin-Prozedur (Block 240).
Das Ergebnis der Login-Prozedur ist, dass die Nutzertabelle 96 nun eine eindeutige Beschreibung des Dualdekor-Nutzers enthält (seine Persönlichkeit), welche das Listenermodul 280 erzeugte für diesen Nutzer während der Login-Prozedur. Spezifischer ausgedrückt, umfasst die Beschreibung die Nutzer_ID, welche nun assoziiert ist mit den Adressen der GCB- und UCB-Datenstrukturen des Nutzers. Weil es nicht möglich ist diese Adressen zu ändern auf Grund der Art, in welcher sie zugewiesen sind durch das emulierte System, würde jede Änderung in der Nutzer_ID-Information korrekter detektiert werden als eine Verletzung des vertrauenswürdigen Pfads des Host-Systems, welcher durch seine Login-Prozedur aufgestellt wurde. Des Weiteren wird die Nutzerbeschreibungsinformation auch verschlüsselt, was weiter die Sicherheit gewährleistet darin, dass sie nicht unterscheidbar ist in dem Fall eines Speicher-Dumps.

Befehlausführungsfluss

Die vorliegende Erfindung verwendet die eindeutigen Nutzerbeschreibungen, die enthalten sind in Nutzertabelle 96 beim Ausführen von Sicherheitsüberprüfung während der Ausführung von Befehlen, die durch einen Nutzer eingegeben werden, um nicht-Dualdekor-(nicht autorisierten Host)-Nutzer davon abzuhalten, derartige Befehle oder Funktionen aufzurufen. Fig. 3a und 3b illustrieren den gesamten Nutzerbefehlsausführungsfluss. Bezug nehmend auf Fig. 3a repräsentieren die mit 300 bis 306 bezeichneten Kreise die verschiedenen Arten von Befehlen, welche einem Nutzer zur Verfügung stehen. Von besonderer Relevanz für die vorliegende Erfindung sind die Befehle, welche als ein Teil der Dualdekorfunktionalität enthalten sind. Wie oben diskutiert ist, sind die verschiedenen Komponenten von Block 28 erweitert worden. Spezifischer ausgedrückt, ist die Dateiverwaltungskomponente 282 modifiziert worden, um die notwendigen Haken und Mechanismen zu inkorporieren, welche jeden der verschiedenen Typen von LK- Befehlen unterstützen. Die Befehlshandhabungseinheit 284 ist erweitert worden, um Mechanismen zu enthalten, welche die CPX- und XSH-Befehle zusätzlich zu verschiedenen Aspekten des LK-Befehls zu unterstützen.
Während des Betriebs, wenn ein Befehl ausgegeben wird durch einen Nutzer über eine Endgerätvorrichtung, ruft der Befehl einen Befehlsprozessor (nicht gezeigt) auf, der innerhalb Block 28 enthalten ist. Der Befehlsprozessor ist eine Systemsoftwarekomponente, welche jede Befehlszeile liest, die durch einen Nutzer durch ein Endgerät oder von einer Steuerdatei eingegeben worden ist, und gibt ihn dann an den geeigneten Befehlshandhaber innerhalb des Blocks 286 zur Ausführung weiter.
Im Fall von bestimmten Typen von Dualdekorbefehlen und Funktionen veranlasst das Verarbeiten eines Dualdekorbefehls die Erzeugung eines speziellen Überwachungsaufrufs durch den bestimmten Befehlshandhaber. Dies wird getan zum Zweck des Erhaltens notwendiger Ressourcenidentifikationsinformation wie z. B. einen logischen Ressourcenzahl-(LRN)-Wert, der erforderlich ist zum Kommunizieren mit Systemstasks und Vorrichtungen. Danach veranlasst der Befehlshandhaber direkt oder indirekt die Erzeugung einer Anforderung für I/O- Überwachungsaufruf (RQIO).
Es wird festgestellt, dass in dem Fall des Linkbefehls dieser Befehl durchgeführt werden kann, ohne eine Dualdekorfunktion aufzurufen. Das heißt, in dem emulierten System kann jeder Befehl verwendet werden, um eine Verbindung innerhalb eines Verzeichnisses oder einer Datei aufzubauen, ohne die Dualdekorfunktionalität aufzurufen. Nur wenn der Link-Mechanismus tatsächlich verwendet wird, um auf Host-Dateien zuzugreifen, kann die Dualdekorfunktionalität aufgerufen werden. Somit, wie in Fig. 3a angedeutet ist, werden andere Überwachungsaufrufe geprüft durch die Dateiverwaltungskomponente 284, um zu bestimmen, ob Zugriff gemacht wird auf das Host-Dateisystem unter Verwendung von Link- Dateien oder Pipes (Block 308). Wenn dies der Fall ist, gibt die Dateiverwaltungskomponente 284 eine Anforderung für einen I/O-Überwachungsaufruf aus. Wenn kein derartiger Zugriff gemacht wird, dann wird der Befehl ausgeführt durch das emulierte System in der normalen Weise (Block 310).
Wie von Fig. 3a gesehen werden kann, resultiert der RQIO-Überwachungsaufruf an die EMCU 73 durch jede der Dualdekor-aufgerufenen Komponenten 28 in der Durchführung eines Nutzerniveau-Überwachungscheckes durch einen der Hochniveauserver 92 oder 94, ausgewählt als eine Funktion des Typs von Dualdekorbefehlen. Detaillierter gesagt, in dem Fall von bestimmten Typen von Dualdekorfunktionen (z. B. CPX-Befehl) umfasst die begleitende IORB-Datenstruktur von RQIO-Überwachungsaufrufinformation, welche den Typ von geforderter I/O- Operation spezifiziert und ob oder ob nicht ein Host-Serverprozess erzeugt worden ist, um die Operation auszuführen. Unter der Annahme, dass kein Serverprozess erzeugt worden ist, wie durch den LRN-Wert, der in dem RCT-Eintrag enthalten ist, bestimmt wird, transferiert EMCU 73 die Anforderung IORB durch Einreihen desselben in den Warteschlangenabschnitt des MQI 84 von entweder dem dynamischen Serverhandhaber 92 im Fall der CPX- und XSH-Befehle oder in den Warteschlangenabschnitt des NTD-Servers 94 im Fall von XSH-Befehlen.
Unter der Annahme, dass die Anforderung weitergegeben worden ist an den dynamischen Serverhandhaber 92, gemäß der vorliegenden Erfindung, führt DSH 92 die Nutzerniveausicherheitsüberprüfung durch, um zu validieren, dass der Befehl ausgegeben worden ist durch einen vertrauenswürdigen Dualdekornutzer, was sicherstellt, dass die Systemsicherheit nicht kompromittiert wird (Block 312). Spezifischer ausgedrückt, bestimmt DSH 92, ob der Nutzer legitim eingeloggt ist mit einem validen Host-Passwort. Dies wird erledigt durch Validieren der Persönlichkeit des Nutzers durch zunächst Erhalten der UCB- und GCB-Adressen von dem geteilten Speicher für den Nutzer, welcher die Dualdekorfunktion aufruft durch Information, die in der IRB-Struktur gespeichert ist, erhalten von dem TCB, dessen Adresse enthalten ist in dem IORB. Diese Adressen werden verglichen mit den verschlüsselten Adressen des Beschreibungseintrags für diesen Nutzer, gespeichert in der Nutzertabelle 96. Diese Operation wird ausgeführt durch die Verwendung einer gemeinsamen Getuseraccescontroll-Routine.
Die Useracces-Routine veranlasst das Verschlüsseln der gegenwärtigen Nutzerdeskriptorinformation (d. h. User_ID, GCB- und UCB-Adressen) und ein Verglich dieser drei Komponenten von Information mit der verschlüsselten Information, die von der Nutzertabelle 96 erhalten wird. Wenn es keinen identischen Vergleich gibt in dem Fall aller drei Felder, dann bedeutet dies, dass der gegenwärtige Nutzer nicht vertrauenswürdig ist und die Sicherheit kompromittieren wird. Das heißt, die Useracces-Routine verifiziert, dass die GCB- und UCB-Adressen, die mit der User_ID, die während dem Login verwendet wird, nicht geändert worden sind.
Wenn die Nutzersicherheit nicht validiert werden kann, unternimmt DSH 92 keine Aktion, um eine Verbindung zu erstellen, sondern meldet einfach die Nutzerniveau-Sicherheitsverletzung an den Nutzer (Block 316). Abhängig von dem Typ von Dualdekorbefehl oder Operation können andere Aktionen unternommen werden durch die Ausführungskomponente, welche die Anförderung seitens des Nutzers initiiert hat. Zum Beispiel im Fall der Dateiverwaltungskomponente 284 kann der Task, welcher versucht hat, die Operation auszuführen, getötet werden. Weil DSH 92 keine Aktion unternahm, um die angeforderte Verbindung zu erstellen, hat der Nutzer keinen Weg, den Dualdekorbefehl oder Funktion auszuführen.
Wenn die Nutzersicherheit validiert ist (Block 314), dann öffnet DSH 92 die Verbindung zwischen dem geeigneten Server und der Ausführungskomponente, welche den Dualdekorbefehl oder die Funktion seitens des Nutzers aufgerufen hat. Spezifischer ausgedrückt, wie in Fig. 3b gezeigt ist, bestimmt er zunächst, welcher Server die Anforderung behandeln muss durch Referenzieren der Vorrichtungstypinformation, die in dem assoziierten RCT enthalten ist. Wenn kein Server des spezifizierten Typs erzeugt worden ist oder zugewiesen werden kann, dann erzeugt DSH 92 einen Serverprozess durch den Host- Gabelsystemaufrufmechanismus und leitet die gesamte Information über den Nutzer an den Server weiter durch MQI 84 (Blcok 318). Spezifischer ausgedrückt, wird der IORB eingereiht durch DSH 92 in die MQI-Warteschlange, die zugewiesen ist zu dem Server, der Dualdekorbefehle oder Funktionen auszuführen hat. Als nächstes baut der DSH 92 die Verbindung zwischen dem zugewiesenen Server und dem Nutzer auf, so dass alle künftigen Anforderungen direkt an diesen Server gehen. Dies wird getan durch Modifizieren der RCT, so dass alle nachfolgenden Anforderungen direkt an diesen Server gesendet werden.
Wie in Fig. 3b angedeutet ist, führt der zugewiesene Server eine Zugriffsüberprüfung durch auf dem Datei- oder Verzeichnisniveau auf der Anforderung (Block 320). Dies wird getan dadurch, dass der Server einen Aufruf macht, um eine Zugriffsfunktion zu bekommen, welche durch zusätzliche Aufrufe bestimmt, ob die bestimmte Nutzer-ID den spezifischen Typ von Operation auf einer gegebenen Datei durchführen kann. Die gleiche gemeinsame Routine wird verwendet durch jeden der verschiedenen Typen von Servern, um diesen Typ von Zugriffsüberprüfung durchzuführen.
Die Zugriffsüberprüfung beinhaltet Referenzieren der Inode-Zulassungsdateien 704 durch Systemaufrufe an Kernel-Prozessverwaltung 70. Wie oben angedeutet ist, umfassen die Inode-Dateien 704 Dateiinhaberidentifikationsinformation (d. h. individuelle Inhaber und Gruppeninhaber und die Sätze von Nutzern, die Zugriffsrechte auf die Datei haben) Dateitypinformation (z. B. regulär, Verzeichnis, FIFO- Pipes) und Dateizugriffszulassungsinformation. Diese erhält alle Zulassungen bei den bestimmten Nutzer-Inode und verifiziert, ob oder ob nicht der Nutzer die erforderlichen Zulassungen hat. Das Ergebnis ist, dass ein 3-Bite-Code erzeugt wird durch den Server zum Angeben der Lese, Schreib und Ausführungszulassungen. Wenn es eine Zugriffsverletzung gibt, wird diese Information verwendet beim Berichten des Typs von Verletzung an die ES-Ausführungskomponente, welche die Anforderung ausgeben hat (Blöcke 320 und 324). Wie in Fig. 3b angedeutet ist, wenn der Server feststellt, dass Zugriff valide ist, dann führt der Server des spezifizierten Dualdekorbefehl oder die Funktion durch und berichtet die Ergebnisse an ES-Nutzer über MQI 84 (Block 326).
Die Zugriffsüberprüfung von Block 320 findet statt bei "Dateizugriffszeit", welche in dem Host-System der erste Schritt ist, der stattfinden muss, um auf die Daten in einer Host-Datei zuzugreifen. In dem Fall eines Host-System- Öffnungssystemsaufrufs, gibt es Information, welche den Typ von Öffnen (z. B. Lesen oder Schreiben) spezifiziert. In dem emulierten System kann ein Dualdekornutzer Befehle oder Funktionen ausgeben, die einem logischen Verbinden der Host-System-Operation vorhergehen, welche äquivalent sind zu dem Öffnen. Zum Beispiel ist dies der Fall, wo der ES-Nutzer eine Datei reserviert durch Ausgeben eines Get-File-Befehls, was das Dateiverwaltungssystem 282 dazu veranlasst, einen RQIO in der Form einer physikalischen Verbindung auszugeben.
In diesem Fall führt der DSH-Server die Sicherheitsoperationen von Blöcken 312 bis 318 wie beschreiben durch. Der zugewiesene Niedrigniveauserver führt die Zugriffssteuerungsüberprüfung von Block 320 auch in der oben beschriebene Weise durch in Antwort auf die physikalische Verbindungsoperation. Weil es jedoch keine Möglichkeit gibt, den Typ von auf der Datei durchzuführende Operation zu bestimmen, werden nur die Verzeichnisdateien überprüft und es wird bestimmt, dass der Nutzer ausreichend Erlaubnis hat, die Datei zu öffnen. Zu der Zeit, wenn das logische Verbinden (Öffnen) ausgegeben wird, was den Typ von Operation zur Dateizugriffszeit angibt, geht diese Anforderung direkt zu dem zugewiesenen Server, der eine extensive Zulassungsüberprüfung durchführt, welche auch das Überprüfen der Nutzerzugriffszulassung umfasst durch die Basis- und erweiterten Zulassungen. Jegliche Verletzung wird in der oben beschriebenen Weise signalisiert.
Die Anordnung erlaubt es, dass die Zugriffsüberprüfung von Block 320 spezifiziert oder zugeschnitten gemacht wird als eine Funktion des Typs von Operation, die durchgeführt wird, um die angemessene Niveausicherheit sicherzustellen. Die Zugriffsüberprüfung kann daher durchgeführt werden auf Öffnen, Lesen oder Schreiben, wie es nötig ist. Somit wird enge Sicherheit aufrechterhalten unabhängig von dem Typ von Dualdekorbefehl oder Funktion, welcher erweitert werden. Des Weiteren verbessert die Durchführung von Zugriffsüberprüfung an dieser Stelle die Sicherheit der emulierten Systeme, bei welchen es nicht immer möglich war, den Typ von angeforderten Zugriff zu bestimmen, bevor eine anfängliche Phase der Operation stattfinden durfte.
Vom obigen kann gesehen werden, wie die vorliegende Erfindung Dualdekorbefehle und Funktionen verarbeitet in einer Weise, welche das Niveau von enger Sicherheit aufrechterhält, was charakteristisch ist für das Host-System 54. Sie erreicht dies durch Integrieren von Dualdekorfunktionen innerhalb der verschiedenen Ausführungsdienstkomponenten des emulierten Systems und durch Hinzufügen von speziellen Überwachungsaufrufen und zusätzlichen Servereinrichtungen zu der Emulationsausführungsniveauschicht, um das Host-System- Betriebssystem in Takt verbleiben zu haben. Anhang A Dualkorkomponenten

Anhang B

Dualdekorbefehle

1. Der CPX-Befehl ist ein Dualdekorbefehl, der Dateien zwischen dem emulierten System und dem Host-System kopiert. Das CPX-Befehlsformat ist wie folgt:
CPX Source_pathname destination_pathname [ctl_args]
Argumente:
Source_pathname
Dieses Argument entspricht dem Pfadnamen der zu kopierenden Datei. Host-Pfadnamen müssen in doppelte Anführungszeichen eingeschlossen werden, müssen komplette Pfadnamen sein und mit x: oder X: beginnen. Wenn der Pfadname nicht mit x: beginnt, wird von ihm angenommen, dass er eine emulierte Systemdatei ist.
destinations_pathname
Dieses Argument entspricht dem Pfadnamen der Datei, auf die zu kopieren ist. Das gleiche trifft zu auf das Benennen der Pfadnamen.
ctl_args
Keines oder beliebige der folgenden Steuerargumente können verwendet werden:
- BINARY -B -TEXT -T
Um zu spezifizieren, ob die gerade kopiert werdende Datei kopiert wird als eine binäre Datei oder eine Textdatei.
- CLONE clone_pathname -SEQ -S_R
Setzt Dateiattribute einer Datei, die gerade erzeugt wird auf einem emulierten System unter Verwendung einer von den drei Optionen.
- CLONE clone_pathname -C clones_pathname
Erzeugt eine Datei unter Verwendung der Attribute der emulierten Systemdatei, spezifiziert durch clone_pathname.
- SEQ
Erzeugt eine emulierte System UFAS-sequenzielle Datei mit 512 Bit Sektoren.
- S_R
Erzeugt eine emulierte System-UFAS-stringbezogene Datei mit 512 Bit Sektoren.
Default: -S_R (Stringbezogen)
- DELETE -DL
Löscht die Quellendatei nachdem die Kopie komplett ist.
- LIST -LS
Gibt Bestätigungsbotschaften aus.
2. Der LK-Befehl ist ein Dualdekorbefehl, der links zwischen emulierten Systemdateien und Host-Dateien erzeugt oder links auf benannte Pips erzeugt. Das LK-Befehlsformat ist wie folgt:
LK GCOSNAME "X:xpath" [-BINARY -TEXT][-FILE -PIPE] Argumente:
- BINARY -BIN -B -TEXT -TXT -T
Spezifiziert, ob die Pipe oder Link, welche gerade erzeugt wird, eine binäre Pipe oder Link ist oder eine Text-Pipe oder Zeile.
Default: Binäre Datei.
xpath
Bestimmt einen Host-Pfadnamen für die Link.
- FILE
Spezifiziert einen Link zu einer Datei. Nicht mit -PIPE verwenden. GCOSNAME
Bestimmt den emulierten Systemnamen des Links.
- PIPE
Spezifiziert eine benannte Pipe. Nicht mit -FILE verwenden.
3. Der XSH-Befehl ist ein Dualdekorbefehl, der es einem Nutzer erlaubt, Host-Befehle von einem emulierten Systemendgerät ablaufen zu lassen. Das XSH-Befehlsformat ist wie folgt:
XSH ["xcommand [&]"]
Argumente:
"xcommand [&]"
Bestimmt einen Host-Befehl, den der Nutzer ausführen will. und
Bestimmt das Ablaufen des Befehls im Hintergrund (Asynchron).
Für den Fachmann wird es klar werden, dass viele Änderungen an der bevorzugten Ausführungsform der vorliegenden Erfindung gemacht werden können.

Claims

1. Host-System mit einem Speicher, der in geteilte und Host- Speicherbereiche organisiert ist, und einer Hardware-Plattform mit einer Mehrzahl von Eingabe/Ausgabevorrichtungen, die operativ verbunden sind zum Ausführen von Host-Systemanweisungen und zum Emulieren der Ausführung emulierter Systeminstruktionen durch einen Emulator, der als ein Anwendungsprozess auf dem Host-System läuft, wobei der Emulator eine Anzahl emulierter Systemausführungsdienstkomponenten umfasst, welche in dem geteilten Speicherbereich arbeiten, mit einem Listenermodul und einer Befehlshandhabungseinheit, die operativ miteinander gekoppelt sind, und einem Interpreter, einer Emulatorüberwacher-Aufrufeinheit EMCU und Server-Einrichtungen, die in dem Host-Speicherbereich arbeiten, wobei das Host-System weiter Betriebssystem-Einrichtungen aufweist zum Bereitstellen einer Anzahl von Diensten für Host-Programme, wobei die Betriebssystem-Einrichtungen gekoppelt sind mit der Vielzahl von Eingabe/Ausgabevorrichtungen und mit der EMCU, wobei das Host- System weiter Validationsmittel umfasst zum Erlauben nur vertrauten Emulationssystemnutzern, auf Host-System-Einrichtungen zuzugreifen, durch einen vorbestimmten Satz von dualen Dekorbefehlen, wobei die Validationsmittel aufweisen:

Nutzeridentitätsvalidationsmittel, die in dem Listenermodul enthalten sind, wobei die Nutzervalidationsmittel in Antwort auf jede Login- Prozedur, die durch einen Nutzer des emulierten Systems initiiert wird, verifizieren, dass dem Nutzer Zugriff gegeben worden ist auf die Einrichtungen, durch Erzeugen eines speziellen Überwacheraufrufs zum Veranlassen der EMCU, vorbestimmte der Host-Dienste aufzurufen zum Validieren, dass der Nutzer ein autorisierter Host-System-Nutzer ist und zum Veranlassen der Erzeugung eines eindeutigen Benutzerbeschreibungseintrags für jeden validierten Benutzer, um nachfolgende Benutzerebenevalidierungen jeder Nutzeridentität des emulierten Systems durchzuführen;

einen Nutzer-Tabellen-USTBL-Mechanismus, der in dem Host- Speicherbereich angeordnet ist, wobei der USTBL-Mechanismus eine Anzahl von Stellen aufweist zum Speichern des eindeutigen Nutzerbeschreibungseintrags, der durch die EMCU erzeugt wird; und

wobei die Server-Einrichtungen erste Server-Handhabungsmittel umfassen inklusive Nutzersicherheitsvalidationsmittel, wobei die Sicherheitsvalidationsmittel in Antwort auf jede Eingabe/Ausgabeanforderung, erzeugt durch die Befehlshandhabungsmittel, auf einen Nutzer des emulierten Systems, der Zugriff auf die Host-Einrichtungen fordert durch einen der vorbestimmten Befehle, eine Validationsoperation hinsichtlich des Nutzers des emulierten Systems durchführt durch Zugreifen auf den Nutzertabellenmechanismuseintrag, der dem Nutzer zugeordnet ist, der Zugriff fordert, um sicherzustellen, dass der Befehl durch einen vertrauten Nutzer ausgegeben worden ist und nicht die Host-Systemsicherheit beeinträchtigt, und die ersten Server-Handhabungsmittel die Ausführung von Befehlen nur dann freigeben, wenn die Validationsoperation bestätigt, dass der Befehl durch einen vertrauten Nutzer ausgegeben worden ist.

2. Host-System gemäß Anspruch 1, bei welchem jeder eindeutige Nutzerbeschreibungseintrag Beschreibungsinformation des emulierten Systems umfasst, zugeordnet dem Nutzer durch die Ausführungsdienstkomponenten, welche nicht modifizierbar durch den Nutzer sind.

3. Host-System gemäß Anspruch 2, bei welchem die Beschreibungsinformation des Nutzers des emulierten Systems, verwendet um die Validationsoperation auszuführen, einen ersten Anteil umfasst mit Nutzer-ID- Information und zweite und dritte Anteile mit Adressen vorbestimmter Datenstrukturen, genutzt durch die Ausführungsdienstkomponenten, um den Nutzer eindeutig zu identifizieren.

4. Host-System gemäß Anspruch 3, bei welchem die ersten Server- Handhabungsmittel die Validationsoperation durchführen durch Vergleichen der Anteile der Beschreibungsinformation des Nutzers des emulierten Systems, die zuvor in den Nutzertabellenmechanismus gespeichert worden ist als ein Eintrag für den Nutzer mit entsprechenden Anteilen der Beschreibungsinformation des Nutzers des emulierten Systems, erhalten von dem emulierten Speicherbereich, erhalten durch den ersten Server- Handhaber, der einem gegenwärtigen Nutzer zugeordnet ist, der die Host- System-Einrichtungen aufruft.

5. Host-System gemäß Anspruch 4, bei welchem die ersten Server- Handhabungsmittel auf Bestimmen, dass es keinen identischen Vergleich gibt, der darauf hinweist, dass der gegenwärtige Nutzer vertrauensunwürdig ist, das Auftreten einer Nutzersicherheitsverletzung signalisiert, und nicht eine Serie von Operationen zum Ermöglichen der Ausführung der geforderten Operation initiiert.

6. Host-System gemäß Anspruch 4, bei welchem die ersten Server- Handhabungsmittel auf Bestimmen, dass es einen identischen Vergleich gibt, der keine Änderung in der Nutzerpersonalität identifiziert, was bestätigt, dass der gegenwärtige Nutzer vertrauenswürdig ist, eine Serie von Operationen initiiert zum Ermöglichen der Ausführung der geforderten Operation.

7. Host-System gemäß Anspruch 1, bei welchem die EMCU Mittel zum Validieren umfasst, dass das Listenermodul die Quelle des speziellen Überwachungsaufrufs ist.

8. Host-System gemäß Anspruch 6, bei welchem die ersten Server- Handhabungsmittel Mittel umfassen zum Feststellen, welcher Typ von Server gefordert ist, um die Anfrage zu handhaben, und Mittel zum Zuordnen zweiter Server-Mittel niedriger Ebene zum Handhaben der Anfrage als Operationen der Serie von Operationen.

9. Host-System gemäß Anspruch 8, bei welchem die Mittel zum Zuordnen arbeiten, um dynamisch Server zu schaffen, und gemäß einem vorbestimmten Kriterium zuordnen.

10. Host-System gemäß Anspruch 8, bei welchem die Server-Mittel der zweiten niedrigeren Ebene Zugriffssteuermittel umfassen zum Durchführen einer Zugriffssteuerungsüberprüfung zum Aufstellen, dass der Nutzer die erforderlichen Zugriffserlaubnisse hat, um die geforderte Operation unter Verwendung der Host-Einrichtungen durchzuführen.

11. Host-System gemäß Anspruch 10, bei welchem die ersten Server- Handhabungsmittel des Weiteren Mittel umfassen zum Herstellen einer Verbindung zwischen den zugeordneten Server-Mitteln der zweiten niedrigeren Ebene und dem gegenwärtigen Nutzer, so dass alle nachfolgenden Anforderungen direkt zu dem zugewiesenen Server gehen als ein Teil der Serie von Operationen, die der Validation des Zugriffs durch die Zugriffssteuermittel folgen.

12. Host-System gemäß Anspruch 11, bei welchem die Server-Mittel niedrigerer Ebene die Validation von Zugriffserlaubnissen durchführen durch die Zugriffssteuermittel zu einer Zeit, wenn Zugriff stattzufinden hat.

13. Host-System gemäß Anspruch 8, bei welchem das Betriebssystem Inode- Erlaubnis-Dateien umfasst, welche Zugriffserlaubnisse definieren für jede Datei des Host-Systems, wobei die Zugriffssteuermittel eine Anzahl von Systemaufrufen an das Betriebssystem erzeugen zum Validieren des Nutzerzugriffs auf der Basis von sowohl Basis- als auch erweiterter Erlaubnisse, die durch die Inode-Erlaubnisdateien definiert sind.

14. Host-System gemäß Anspruch 1, bei welchem der vorbestimmte Satz von Befehlen sowohl neue als auch Erweiterungen zu Befehlen umfasst, welche durch das emulierte System benutzt werden.

15. Host-System gemäß Anspruch 1, bei welchem der vorbestimmte Satz von Befehlen einen Satz von Basis-Dual-Dekorfunktionen definiert, die erforderlich sind zum Integrieren sowohl der Host- als auch der emulierten Systemoperationen.

16. Host-System gemäß Anspruch 15, bei welchem Kombinationen der Dual- Dekorfunktionen, gewählt durch Kombinationen des vorbestimmten Satzes von Befehlen ermöglichen, dass emulierte Systemnutzeroperationen durchgeführt werden durch sowohl das emulierte System als auch das Host-System in einer Zusammenarbeitsweise.