Projektstudium
SS98 - distributed computing
Die abstrakte Klasse java.security.Permission ist der Vorfahre von allen Erlaubnissen. Sie definiert die wesentliche Funktionalität, die für alle Permissions benötigt wird. Jede Permission Instanz wird typischerweise durch die Übergabe von ein oder mehr Stringparametern an den Konstruktoren erstellt. In den meisten Fällen mit zwei Parametern, der erste ist normaler weise der name vom Zielobjekt (wie der Name von einer Datei), und der zweite Parameter ist die Aktion, die Ausgeführt werden soll (wie Lesen oder Schreiben). Generell kann eine Menge von Aktionen zusammen als ein Komma getrennter String übergeben werden.
Die java.security.PermissionCollection Klasse hält eine homogene Kollektion von Permissions. Das heißt, jede Instanz von der Klasse hält jeweils nur Permissions vom gleichen Typ.
Die Klasse java.security.Permissions wurde entwickelt im gegensatz zu java.security.PermissionCollection eine heterogene Kollektion von Permissions zu halten. Grundsätzlich ist es eine Kollektion von java.security.PermissionCollection Objekten.
Erinnern wir uns das der interne Zustand einer Sicherheitspolitik normalerweise durch die Permissions Objekt, die jeweils verbunden mit CodeQuellen sind, repräsentiert wird. Nach der dynamischen Eigenschaft von Java, ist es möglich, daß wenn der Politik ein aktueller Code gegeben wird, in der eine besondere Permission Klasse implementiert wird, die bis jetzt noch nicht geladen wurde und im Java Laufzeit System definiert wurde, dann wird diese Permission in der java.security.UnresolvedPermission Klasse gespeichert. Analog zu den anderen Klassen speichert java.security.UnresolvedPermissionCollection eine Kollektion von UnresolvedPermission Permissions.
Während der Zugriffskontroll wird eine "unresolved permission" resolved und the entsprechende Entscheidung getroffen. Es wird ein neues Objekt des entsprechenden Klassentyps instanziert, wenn möglich basierend auf den Informationen aus der UnresolvedPermission. Dieses neue Objekt ersätzt die UnresolvedPermission, die gelöscht wird. Wenn die Permission immer noch unresolvable ist, wird die Permission ungültig.
Das Ziel der java.io.FilePermission Klasse kann wie folgt definiert werde. Verzeichnis und Dateiname sind Strings, welche keine Leerzeichen enthalten können.
file
directory (same as directory/)
directory/file
directory/* (all files in this directory)
* (all files in the current directory)
directory/- (all files in the file system under this directory)
- (all files in the file system under the current directory)
"<<ALL FILES>>" (all files in the file system)
Beachte, daß "<<ALL FILES>>" ein spezieller String ist, der alle Dateien in einen System bezeichnet. In einem Unixsystem sind das alle Dateien unter dem root-Verzeichnis. In einen MS-DOS System sind das alle Dateien von allen Laufwerken.
Die möglichen Aktionen sind:
Die folgenden Beispiele sind gültige Codestücke zum erzeugen von file permissions:
import java.io.FilePermission;
FilePermission p = new FilePermission("myfile", "read,write");
FilePermission p = new FilePermission("/home/gong/", "read");
FilePermission p = new FilePermission("/tmp/mytmp", "read,delete");
FilePermission p = new FilePermission("bin/*", "execute");
FilePermission p = new FilePermission("*", "read");
FilePermission p = new FilePermission("/-", "read,execute");
FilePermission p = new FilePermission("-", "read,execute");
FilePermission p = new FilePermission("<<ALL FILES>>", "read");
In diesen Klassen interpritiert die implies() Methode das Dateisystem richtig. Als Beispiel:
FilePermission("/-", "read,execute")
implies FilePermission("/home/gong/public_html/index.html", "read"),
und FilePermission("bin/*", "execute")
implies FilePermission("bin/emacs19.31", "execute").
Beachte, diese Strings werden in platformabhängigen Format angegeben. Als Beispiel, um einen Lesezugriff auf der Datei "Projekt.txt" im "temp" Verzeichnis auf den C Laufwerk eines Windowssystem wiederzugeben, müßte man folgendes angeben:
FilePermission p = new FilePermission("c:\\windows\\temp\\Projekt.txt", "read");
Der doppelte backslash ist nötig um einen einfachen backslash anzugeben, weil der String von java.io.StreamTokenizer geparst wird, der "\" als escape strings interpretiert. Es ist leider nötig die Strings in Platformabhängigen Format anzugeben, bis eine einheitliche Datei Beschreibungssprache existiert.
Es ist außerdem noch zu beachten, das ein Verzeichnis als Ziel definiert mit einer "read" Aktion nur die Erlaubnis erteilt den Inhalt des Verzeichnisses aufzulisten:
FilePermission p = new FilePermission("/home/gong/", "read");
Die Erzeugung von anderen Permissions sieht nahezu identisch mit der File Permission aus.
Die java.security.BasicPermission ist von der Permission Klasse abgeleitet und wird im wesentlichen für Permissions benutzt, die die selben Namenskonventionen wie BasicPermission haben sollen. Diese folgen den standard hierachischen Namenskonventionen, so wie sie bei der Bennenung von Klassen verwendet werden.
Der Aktion String wird in dieser Klasse nicht verwendet. Subklassen werden verwendet um auf der Basis von BasicPermission diese um Aktionlisten zu erweitern. Einige der von den BasicPermission Subklassen sind java.lang.RuntimePermission, java.security.SecurityPermission, java.util.PropertyPermission, und java.net.NetPermission.
Eine weitere interessante Klasse ist die java.lang.RuntimePermission. Die Ziele für eine RuntimePermission werden durch einen beliebigen String dargestellt. Der Permission wird keinerlei Aktionliste zugeordnet. Das heißt, daß die RuntimePermission "exit" bedeutet die Erlaubnis das Java Runtime System zu verlassen. Einige wichtige Ziele sind hier aufgelistet:
createClassLoader
exit
setFactory
setIO
thread
Class.getProtectionDomain
Class.setProtectionDomain
fileDescriptor.read
fileDescriptor.write
loadLibrary.{library name}
package.access.{package name}
package.define.{package name}
reflect.declared.{class name}
print.queueJob
Nach dem wir nun die schon eingebauten Permissions kennen gelernt haben, ist zu betrachten wie einfach oder schwer es ist selbst neue Permissionstypen zu erzeugen. Es ist essential, daß keiner außer JavaSoft die eingebauten Permissions in JDK erweitet. Um nun aber neue Permissions zu erzeugen ist der Folgende Schritt von nöten. Hier für ein kleines Beispiel:
Der Entwickler der Firma Mircosoft will eine Permission "breath Air" erzeugen. Als erstes erzeugt er eine neue Klasse com.Mircosoft.Permission und eine andere Klasse com.Mircosoft.AirPermission die von der Klasse com.Mircosoft.Permission abgeleitet ist. Es ist wichtig zu klären, das die "implies" Methoden korrekt implementiert sind.
public class com.Mircosoft.Permission extends java.security.Permission
public class com.Mircosoft.AirPermission extends com.Mircosoft.Permission
Als zweitess werden dieses Klassen in dem Anwendungspacket inkludiert. Dann wird der String, der diese Permission repräsentiert in die "policy" Datei eingetragen, so daß diese Permission automatisch konfiguriert werden kann.
Ein Beispiel von einen "policy" Eintrag der das Atmen in Deutschland erlaubt ist :
permission com.Mircosoft.AirPermission "Germany", "breath";
In den Anwendungsresourcenverwalter, wird die Methode checkPermission des AccesControllers mit den Objekt com.Mircosoft.AirPermission als Parameter aufgerufen.
com.Mircosoft.AirPermission airperm = new com.Mircosoft.AirPermission("Germany", "breath");
AccessController.checkPermission(airperm);
Wenn mehre AirPermissions wie "USA", "Australien" oder ander erlaubt sind, dann kann es nötig sein eine AirPermissionCollection zu implementieren
Neuer Code sollte immer einen Permissiontest beinhalten um den eingebauten Zugangskontrollalgorithmus zu nutzen.
