| Benutzer | | Gäste online: 9
Benutzer online: 0
|
 | |
|
Hinweis: Links zu OpenVMS.org funktionieren nicht. Der Website ist offline. |
|
| SYS$MANAGER:SYLOGIN.COM - störungsfreie Verarbeitungsprüfung von SYLOGIN | | Der OpenVMS-Fachberater - 13-Jul-2010 10:39 UTC | Vom OpenVMS-Fachberater Bob Gezelter
OpenVMS LOGINOUT und CLI-Initialisierung bieten ein mächtiges Werkzeug zur Anpassung individueller OpenVMS-Sessions. Diese Mächtigkeit bringt aber Gefahren mit sich. Fehler in den Anpassungen können leicht zu ungeeigneten Prozess-Kontexten führen, und diese zu Softwaredefekten und Störungen der Systemverfügbarkeit. Durch ein Gerüst zur Fehlerisolation und -diagnose kann man diese Risiken erheblich verringern.
Die allgemeinen Konzepte, Prinzipien und Gefahren bei der Modifikation von Dateien, die während der Prozesserzeugung ausgeführt werden, wurden in einer vorangegangenen Kolumne (SYS $MANAGER:SYLOGIN.COM - Flexibilität erfordert Sorgfalt) besprochen.
Dass es so einfach ist, ein SET VERIFY als erste Zeile in eine Kommandodatei einzufügen, die während der CLI-Initialisierung ausgeführt wird (für DCL SYS$MANAGER:SYLOGIN.COM; im Folgenden SYLOGIN), ist verlockend und sicher effektiv. Aber ein global wirkendes SET VERIFY ist eine extrem grobe Keule. Auf einer einzelnen Workstation oder einem virtuellen System mag es zunächst annehmbar erscheinen, bis man merkt, dass selbst in einer so einfachen Umgebung SYLOGIN von mehr Prozessen verwendet wird, als offensichtlich ist. Die meisten Prozesserzeugungen interessieren beim Debuggen des vorliegenden Problems wenig. Der Overhead durch das zeilenweise DCL-Loggen kann Verzögerungen verursachen, die zu Störungen bei anderer Software führt, was zu einem instabilen oder unbenutzbaren System führen kann. Eine genaue Kontrolle der Umstände, wann das SET VERIFY ausgeführt wird, ist ausschlaggebend dabei, eine benutzbare und stabile Debugging-Umgebung mit minimalen Kollateralschäden zu erzeugen.
Eine sorgfältige Betrachtung des genauen, schon etablierten Prozesskontexts beim Aufruf von SYLOGIN wird zeigen, wie wir das Einschalten der DCL-Verifikation sehr präzise steuern können.
Beim Aufruf des CLI-Initialisierungs-Einsprungpunkts durch LOGINOUT.EXE - in dessen Folge dann SYLOGIN ausgeführt wird - sieht der zugrundeliegende Prozess-Status wie folgt aus:
- der Kommandozeileninterpreter (CLI), angegeben durch den Parameter "CLI" in der SYSUAF (meist DCL), ist etabliert. Das ist der häufigste Fall: SYLOGIN ist SYS$MANAGER:SYLOGIN (bedingt durch die Übersetzung des logischen Namens SYS$LOGIN aus der Systemtabelle). Im allgemeinen wird der Dateityp im logischen Namen weggelassen, was seine Verwendung mit mehreren CLIs (z.B. DCL und MCR) ermöglicht. Welche Datei tatsächlich aufgerufen wird, liegt beim ausgewählten CLI (DCL verwendet den Default-Dateityp .COM, und damit SYS$MANAGER:SYLOGIN.COM).
- Die CLI-Tabelle des Prozesses ist auf den in der SYSUAF angegebenen Wert gesetzt.
- Als Konsequenz wird die Searchlist für die Übersetzung von logischen Namen (LNM$FILE_DEV in LNM$DIRECTORY) per Default auf den LNM$FILE_DEV-Eintrag im systenweiten Verzeichnis LNM$SYSTEM_DIRECTORY gesetzt.
- Der Prozess wird unter dem UIC und Benutzernamen des Benutzers ausgeführt, mit Quoten und Privilegien wie in der aktuellen Authorisierungsdatei angegeben (oder mit den Minimaleinstellungen des Systems aus dessen Parameterdatei)
Die Login-Kommandodatei des Benutzers wird nach Beendigung des systemweiten Logins aufgerufen. Sie wird gefunden durch den Inhalt des Feldes LGICMD, mit Defaults aus den Feldern DEVICE und DIRECTORY.
Der grundlegende Prozesskontext bietet einen guten Rahmen, um viele Aspekte des Prozesses zu steuern, einschließlich des DCL-Verifizierungsflags. Es gibt eine Vielzahl von Möglichkeiten, den Geltungsbereich des SET VERIFY zu beschränken.
Man könnte den Benutzernamen oder UIC verwenden, um die Verwendung des SET VERIFY zu steuern. Das aber wäre ein plumpes Werkzeug, das ständige Änderungen an SYLOGIN erfordern würde. Die Rightslist-Identifier und andere Aspekte des Prozesskontexts bieten wesentlich bessere Möglichkeiten.
Als Verständnishilfe habe ich drei Beispiel-Kommandodateien mit verschiedenen Techniken zur selektiven Aktivierung der DCL-Verifizierung im Demonstrationbereich meiner Firma unter http://www.rlgsc.com/demonstrations/login-dcl-trace.html veröffentlicht.
Zur Sicherheit kann jede der Beispieldateien am Anfang der LOGIN.COM eines Benutzers aufgerufen werden, statt von der systemweiten SYLOGIN. Damit können die Beispiele ohne systemweite Auswirkungen getestet werden. DCLTRACE_RIGHTSLIST.COM zeigt ein einfaches Beispiel, das auf Rightslists basiert. Um auf einfache Weise zu demonstrieren, was möglich ist, nehmen wir an, SYLOGIN wird so modifiziert, dass durch Verwendung eines Rightslist-Identifiers die Verarbeitung für interaktive Prozesse gesteuert wird. Anstatt dass in allen Benutzer-Session jedes DCL-Kommando geloggt wird, kann damit die DCL-Verifikation in den interaktiven Sessions eines einzelnen Benutzers angeschaltet werden, was wesentlich weniger Auswirkungen hat. Es werden Privilegien zur Erzeugung eines Rightslist-Identfiers und seiner Zuweisung an einen bestimmten Benutzer benötigt.
...
$ RIGHTSLIST = "," + F$GETJPI("", "RIGHTSLIST") + ","
$ IF F$LOCATE(",TRACE_LOGIN,", RIGHTSLIST) .NE. F$LENGTH(RIGHTSLIST)
$ THEN
$ SET VERIFY
$ ENDIF
...
Vorteile bei der Verwendung von Rights-Identifiern ergeben sich daraus, dass sie in der Systemliste gespeichert werden, die i.allg. von allen Knoten eines Clusters verwendet wird und auch Reboots überlebt.
Der Pferdefuß des rightslist-basierten Ansatzes ist das Zuweisen und Entziehen des Identifiers TRACE_LOGIN. Arbeiten an der Rightslist (ADD/GRANT/REVOKE in AUTHORIZE) erfordern einen privilegierten Zugang zur SYSUAF-Datei und der Rightslist. Ein solcher Zugang stellt oft ein Problem dar. Das Zuweisen der benötigten Privilegien kompromittiert die Vorgaben an die Systemsicherheit. Ein Eingreifen des Systemadministrators zum An- oder Abschalten der DCL-Verifikation erhöht dessen Arbeitsbelastung und kann zu Verzögerungen führen.
Es wäre wesentlich einfacher, wenn ein solches Feature von Programmierern oder Projektmanagern selbst an- oder abgeschaltet werden könnte, ohne Gefahr für andere Benutzer und ganz bestimmt ohne Eingreifen des Systemadministrators.
Die Tabelle der gruppenweiten logischen Namen kann ebenfalls zur Kontrolle der DCL-Verifikation eingesetzt werden. Dieser alternative Ansatz hat vom rightslist-basierten Ansatz verschiedene Stärken und Schwächen. Die gruppenweiten logischen Namen sind eine weniger globale Ressource, und das benötigte Privileg GRPNAM hat weniger Potential, den Systembetrieb zu stören als SYSPRV o.ä. zum Erzeugen, Zuweisen und Entziehen von Rightslist-Identifiern. Die Nachteile dieser Herangehensweise sind, dass die gruppenweite Tabelle nur lokal auf einem Knoten eines OpenVMS-Clusters existiert, und beim Shutdown verlorengeht (dies kann durch eine Kombination von während des Bootens ausgeführten Kommandodateien und dem Kommando SYSMAN aufgefangen werden). Im Rahmen dieser Einschränkungen ist dieser Ansatz recht effektiv.
DCLTRACE_GROUP.COM prüft den logischen Namen TRACE_LOGIN im Suchpfad für logische Namen, der standardmäßig sowohl die System- als auch die Gruppentabellen beinhaltet. Wenn der logische Name existiert und einen Stringwert "TRUE" hat, wird die DCL-Verifikation eingeschaltet. Der Vorteil des auf logischen Namen basierten Ansatzes ist eine Verringerung der zur Steuerung des DCL-Logging während der Prozesserzeugung benötigten Privilegien. Jeder Benutzer, der die Gruppentabelle von logischen Namen ändern darf, kann nun DCL-Logging für seine Gruppe an- und abschalten, sobald der zugrundeligende Code in SYLOGIN eingefügt wurde.
DCLTRACE_GROUP.COM arbeitet allerdings unpräzise; es kontrolliert DCL-Verifikation beim Login nur für eine ganze Gruppe. Ein verwandtes Beispiel, nämlich DCLTRACE_USERWITHINGROUP.COM, kombiniert die Flexibilität der gruppenweiten logischen Namen mit der Genauigkeit von Benutzernamen. Benutzer mit GRPNAM-Privileg können eine Liste von Benutzernamen definieren und ändern, deren Login-Vorgang geloggt werden soll. An- oder Abschalten der DCL-Verifikation ist nur eine Frage des Einfügens/Entfernens eines Benutzernamens in die/aus der Liste.
Zugegeben, DCLTRACE_USERWITHINGROUP.COM ist ein einfaches Beispiel. Man kann es aber als Ausgangspunkt für einen wesentlich einfacher zu verwaltendes Mechanismus nehmen. Man könnte etwa eine Kommandodatei schreiben, die Benutzernamen in den gruppenweiten logischen Namen TRACE_LOGIN einfügt oder aus ihm entfernt. Natürlich zeigen diese drei Beispieldateien nur exemplarisch die Ansätze, wie man die DCL-Verifikation während des Logins kontrollieren kann. Die Ansätze schliessen sich nicht gegenseitig aus; sie können auf vielerlei Weise kombiniert werden, um den Login-Prozess zu kontrollieren, ohne die Systemsicherheit oder -integrität aufzugeben.
DCL-Verifikation während des Loginprozesses ist ein mächtiges Werkzeug. Mit einem Minimum an Voraussicht kann dieses Tool einer Vielzahl von Benutzern und Entwicklern zur Verfügung gestellt werden, ohne Gefahr für den Systembetrieb oder die Systemsicherheit.
Wie immer begrüße ich Leserkorrespondenz zu den Inhalten dieser Kolumne. Ich bin zu erreichen über den Website meiner Firma unter http://www.rlgsc.com.
Über den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel in dem kürzlich erschienenen Computer Security Handbook, 5. Auflage.
Er veröffentlich außerdem Ruminations - An IT Blog über IT-Themen, die nicht mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
Otiginal auf Bob Gezelters Site
| | Links zum Thema: | Version zum Drucken | |
|
|
|
![[OpenVMS Swoosh]](/images/OpenVMS_VSI_72x88.png)
de.OpenVMS.org![[Future Forward]](/images/swoosh160w.jpg)