java.lang.SecurityManager メソッドに加えられた変更のリストを示し、オーバーライドを実行する際のアドバイスを行います。これらのメソッドの詳細については、SecurityManager クラスの Java ドキュメントを参照してください。
protected boolean inCheck
このフィールドは推奨されなくなり、JDK 内でのこのフィールドの使用はすべて削除されました。inCheck を使う代わりに、
checkPermissionをdoPrivilegedとともに使ってください。
public boolean getInCheck();
このメソッドも推奨されなくなりました。
public SecurityManager();
コンストラクタは、呼び出し元が
RuntimePermission("createSecurityManager")アクセス権を持っていると仮定して、複数の SecurityManager の作成が可能になるように修正されました。
protected native Class[] getClassContext();
変更はありません。この呼び出しは、JDK で変更されたメソッド (
currentClassLoader、currentLoadedClass、classLoaderDepth、inClassLoader) の 1.1 での動作をエミュレートするために使用できます。
protected ClassLoader currentClassLoader();
JDK 1.1 スタイルのセキュリティマネージャでのこのメソッドの典型的な使用方法は、スタックにクラスローダがあるかどうかを調べることです。このとき、クラスローダがない場合は、コードを「信頼できる」ものとして取り扱い、コードにすべての動作を許可します。このメソッドは JDK で修正され、
doPrivilegedを呼び出す信頼できる JDK コード (実際には、java.security.AllPermissionを与えられたすべてのコード) は、1.1 スタイルのセキュリティマネージャに信頼されるものとして取り扱われるようになりました。またこのコードは、システムクラスローダを無視するように修正されました。システムクラスローダとは、システムクラスローダ (ClassLoader.getSystemClassLoader によって返される) またはその上位オブジェクトのひとつに等しいクラスローダであると定義されます。このメソッドは、次の 3 つの場合に
nullコードを返します。
- 実行スタック上のすべてのメソッドが、システムクラスローダまたはその上位オブジェクトの 1 つを使って定義されたクラスからのものである場合
- 最初の「特権付き」呼び出し元 (java.security.AccessController.doPrivileged を参照) までの実行スタック上のすべてのメソッドが、システムクラスローダまたはその上位オブジェクトの 1 つを使って定義されたクラスからのものである場合
- checkPermission を
java.security.AllPermissionアクセス権で呼び出した結果、SecurityExeception がスローされなかった場合このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
protected Class currentLoadedClass();
このメソッドは
currentClassLoaderと同様の方法で修正されました。その時点でのセキュリティコンテキストにAllPermissionが与えられているか、スタック上のすべてのメソッド (存在する場合は、特権を持つ最初の呼び出し元まで) がシステムクラスローダまたはその上位クラスの 1 つを使って定義されたクラスからのものである場合には、nullを返します。このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
protected int classDepth(String name);
動作に変更はありません。このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
protected int classLoaderDepth();
このメソッドは
currentClassLoaderと同様の方法で修正されました。その時点でのセキュリティコンテキストにAllPermissionが与えられているか、スタック上のすべてのメソッド (存在する場合は、特権を持つ最初の呼び出し元まで) がシステムクラスローダまたはその祖先の 1 つを使って定義されたクラスからのものである場合には、-1を返します。このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
protected boolean inClass(String name);
動作に変更はありません。このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
protected boolean inClassLoader();
このメソッドは、
currentClassLoaderが null 以外のクラスローダを返す場合には、true を返します。そのため、このメソッドはcurrentClassLoaderと同じセマンティクスに従います。このメソッドは推奨されなくなりました。代わりに
checkPermissionを使用してください。
public Object getSecurityContext();
このメソッドは、
java.security.AccessController.getContextへの呼び出しとともに作成されたjava.security.AccessControlContextオブジェクトを返します。JDK 1.1 では、このメソッドはデフォルトでnullを返していました。
public void checkPermission(Permission perm);
これは、JDK に新しく追加されたメソッドです。指定されたアクセス権で
java.security.AccessController.checkPermissionを呼び出します。内部的には、JDK は直接AccessControllerを呼び出さずに、常にSecurityManager.checkPermissionを呼び出します。このため、プログラマはこのメソッドをオーバーライドして、監査や GUI ダイアログのような機能を追加することができます。
public void checkPermission(Permission perm, Object context);
これは、JDK に新しく追加されたメソッドです。
contextがAccessControlContextのインスタンスである場合は、AccessControlContext.checkPermissionメソッドが、指定されたアクセス権に従って呼び出されます。
contextがAccessControlContextのインスタンスでない場合は、SecurityExceptionがスローされます。
public void checkCreateClassLoader();
このメソッドは修正されました。
checkPermissionをRuntimePermission("createClassLoader")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkCreateClassLoaderへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkCreateClassLoader() { if (someCustomSecurityCheckFails()) { super.checkCreateClassLoader(); } } }
public void checkAccess(Thread t);
スレッドの引数がシステムスレッド (親が
nullであるスレッドグループに属するスレッド) の場合、このメソッドはRuntimePermission("modifyThread")アクセス権でcheckPermissionを呼び出します。より厳しいポリシーが必要なアプリケーションでは、このメソッドをオーバーライドする必要があります。
このメソッドをオーバーライドする場合は、オーバーライド後のメソッドの最初のステートメントで
super.checkAccessメソッドを呼び出すか、同様のセキュリティチェックを行う必要があります。このメソッドをオーバーライドする場合は、オーバーライド後のメソッドでは、呼び出し元のスレッドが
RuntimePermission("modifyThread")アクセス権を持つかどうかをチェックして、持っている場合には何もせずに終了するようにします。これは、そのアクセス権を与えられたコード (JDK 自体など) がどんなスレッドでも扱えるようにするためです。次に例を示します。
public class MySecurityManager extends SecurityManager { public void checkAccess(Thread t) { // a call to super will throw an exception if someone // is trying to modify a system thread super.checkAccess(t); ... if (someCustomSecurityCheckForOtherThreadsFails()) { // if the check fails, instead of throwing an exception, // call checkPermission, which will throw an exception // if need be checkPermission(new RuntimePermission("modifyThread")); } ... } }
public void checkAccess(ThreadGroup g);
スレッドグループの引数がシステムスレッドグループ (親が
null) の場合、このメソッドは、RuntimePermission("modifyThreadGroup")アクセス権でcheckPermissionを呼び出します。より厳しいポリシーが必要なアプリケーションでは、このメソッドをオーバーライドする必要があります。
このメソッドをオーバーライドする場合は、オーバーライド後のメソッドの最初のステートメントで
super.checkAccessメソッドを呼び出すか、同様のセキュリティチェックを行う必要があります。このメソッドをオーバーライドする場合は、オーバーライド後のメソッドでは、呼び出し元のスレッドが
RuntimePermission("modifyThreadGroup")アクセス権を持つかどうかをチェックして、持っている場合には何もせずに終了するようにします。これは、そのアクセス権を与えられたコード (JDK 自体など) がどんなスレッドグループでも扱えるようにするためです。次に例を示します。
public class MySecurityManager extends SecurityManager { public void checkAccess(ThreadGroup g) { // a call to super will throw an exception if someone // is trying to modify the system thread group super.checkAccess(g); ... if (someCustomSecurityCheckForOtherThreadGroupsFails()) { // if the check fails, instead of throwing an exception, // call checkPermission, which will throw an exception // if need be checkPermission(new RuntimePermission("modifyThreadGroup")); } ... } }
public void checkExit(int status);
このメソッドは修正されました。
checkPermissionをRuntimePermission("exitVM")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkExitへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkExit(int status) { if (someCustomSecurityCheckFails()) { super.checkExit(status); } } }
public void checkExec(String cmd);
このメソッドは修正されました。
checkPermissionをFilePermissionで呼び出します。cmdが絶対パス (java.io.File.isAbsoluteを参照) の場合は、FilePermissionのターゲットとしてそのまま渡されます。cmdが絶対パスでない場合は、特別なターゲット「<<ALL FILES>>」が使用されます。このターゲットを使用する理由は、個別のプラットフォームで実行されるコマンドの実際のパスを判断するのは、環境変数などの要因のために困難なためです。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkExecへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkExec(String cmd) { if (someCustomSecurityCheckFails()) { super.checkExec(cmd); } } }
public void checkLink(String lib);
このメソッドは修正されました。
checkPermissionをRuntimePermission("loadLibrary."+lib)アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkLinkへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkLink(String lib) { if (someCustomSecurityCheckFails()) { super.checkLink(lib); } } }
public void checkRead(FileDescriptor fd);
このメソッドは修正されました。
checkPermissionをRuntimePermission("readFileDescriptor")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkReadへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkRead(FileDescriptor fd) { if (someCustomSecurityCheckFails()) { super.checkRead(fd); } } }
public void checkRead(String file);
このメソッドは修正されました。
checkPermissionをFilePermission(file,"read")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkReadへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkRead(String file) { if (someCustomSecurityCheckFails()) { super.checkRead(file); } } }
public void checkRead(String file, Object context);
このメソッドは修正されました。
contextがAccessControlContextのインスタンスである場合は、AccessControlContext.checkPermissionメソッドが、FilePermission(file,"read")のアクセス権に従って呼び出されます。
contextがAccessControlContextのインスタンスでない場合は、SecurityExceptionがスローされます。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkReadへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkRead(String file, Object context) { if (someCustomSecurityCheckFails()) { super.checkRead(file, context); } } }
public void checkWrite(FileDescriptor fd);
このメソッドは修正されました。
checkPermissionをRuntimePermission("writeFileDescriptor")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkWriteへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkWrite(FileDescriptor fd) { if (someCustomSecurityCheckFails()) { super.checkWrite(fd); } } }
public void checkWrite(String file);
このメソッドは修正されました。
checkPermissionをFilePermission(file,"write")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkWriteへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkWrite(String file) { if (someCustomSecurityCheckFails()) { super.checkWrite(file); } } }
public void checkDelete(String file);
このメソッドは修正されました。
checkPermissionをFilePermission(file,"delete")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkDeleteへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkDelete(String file) { if (someCustomSecurityCheckFails()) { super.checkDelete(file); } } }
public void checkConnect(String host, int port);
このメソッドは修正されました。ポートが -1 でない場合には、
checkPermissionをSocketPermission(host+":"+port,"connect")アクセス権で呼び出します。ポートが -1 の場合は、checkPermissionをSocketPermission(host,"resolve")アクセス権で呼び出します。この動作には JDK 1.1 との一貫性があり、ポートが -1 である場合は、IP アドレスのルックアップが行われていることを示します。
このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkConnectへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkConnect(String host, int port) { if (someCustomSecurityCheckFails()) { super.checkConnect(host, port); } } }
public void checkConnect(String host, int port, Object context);
このメソッドは修正されました。
contextがAccessControlContextのインスタンスである場合は、ポートが -1 に等しくないときには、AccessControlContext.checkPermissionメソッドがSocketPermission(host+":"+port,"connect")アクセス権で呼び出されます。ポートが -1 に等しいときは、checkPermissionがSocketPermission(host,"resolve")のアクセス権に従って呼び出されます。
contextがAccessControlContextのインスタンスでない場合は、SecurityExceptionがスローされます。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkConnectへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkConnect(String host, int port, Object context) { if (someCustomSecurityCheckFails()) { super.checkConnect(host, port, context); } } }
public void checkListen(int port)
このメソッドは修正されました。ポートが 0 でない場合は、
checkPermissionをSocketPermission("localhost:"+port,"listen")で呼び出します。ポートが 0 の場合は、checkPermissionをSocketPermission("localhost:1024-","listen")で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkListenへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkListen(int port) { if (someCustomSecurityCheckFails()) { super.checkListen(port); } } }
public void checkAccept(String host, int port);
このメソッドは修正されました。
checkPermissionをSocketPermission(host+":"+port,"accept")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkAcceptへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkAccept(String host, int port) { if (someCustomSecurityCheckFails()) { super.checkAccept(host, port); } } }
public void checkMulticast(InetAddress maddr);
このメソッドは修正されました。
checkPermissionをSocketPermission(maddr.getHostAddress(),"accept,connect")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkMulticastへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkMultiCast(InetAddress maddr) { if (someCustomSecurityCheckFails()) { super.checkMultiCast(maddr); } } }
public void checkMulticast(InetAddress maddr, byte ttl);
このメソッドは修正されました。
checkPermissionをSocketPermission(maddr.getHostAddress(),"accept,connect")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkMulticastへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkMultiCast(InetAddress maddr, byte ttl) { if (someCustomSecurityCheckFails()) { super.checkMultiCast(maddr, ttl); } } }
public void checkPropertiesAccess();
このメソッドは修正されました。
checkPermissionをPropertyPermission("*", "read,write")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkPropertiesAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkPropertiesAccess() { if (someCustomSecurityCheckFails()) { super.checkPropertiesAccess(); } } }
public void checkPropertyAccess(String key);
このメソッドは修正されました。
checkPermissionをPropertyPermission(key, "read")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkPropertyAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkPropertyAccess(String key) { if (someCustomSecurityCheckFails()) { super.checkPropertiesAccess(key); } } }
public boolean checkTopLevelWindow(Object window);
このメソッドは修正されました。
checkPermissionをAWTPermission("showWindowWithoutWarningBanner")アクセス権で呼び出し、SecurityException がスローされない場合は true を返します。それ以外の場合は false を返します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常 false を返す位置で、
super.checkTopLevelWindowへの呼び出しを行い、super.checkTopLevelWindowの値を返す必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkTopLevelWindow(Object window) { if (someCustomSecurityCheckFails()) { return super.checkTopLevelWindow(window); } else { return true; } } }
public void checkPrintJobAccess();
このメソッドは修正されました。
checkPermissionをRuntimePermission("queuePrintJob")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkPrintJobAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkPrintJobAccess() { if (someCustomSecurityCheckFails()) { super.checkPrintJobAccess(); } } }
public void checkSystemClipboardAccess();
このメソッドは修正されました。
checkPermissionをAWTPermission("accessClipboard")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkSystemClipboardAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkSystemClipboardAccess() { if (someCustomSecurityCheckFails()) { super.checkSystemClipboardAccess(); } } }
public void checkAwtEventQueueAccess();
このメソッドは修正されました。
checkPermissionをAWTPermission("accessEventQueue")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkAwtEventQueueAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkAwtEventQueueAccess() { if (someCustomSecurityCheckFails()) { super.checkAwtEventQueueAccess(); } } }
public void checkPackageAccess(String pkg);
このメソッドは修正されました。最初に、
java.security.Security.getProperty("package.access")を呼び出してコンマで区切られたリストを取得することにより、制限付きのパッケージのリストを得ます。次に、pkgが制限付きパッケージのどれかで開始するかどうか、または等しいかどうかをチェックします。該当する場合には、checkPermissionがRuntimePermission("accessClassInPackage."+pkg)アクセス権で呼び出されます。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドの 1 行目で、
super.checkPackageAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkPackageAccess(String pkg) { super.checkPackageAccess(pkg); ... someCustomSecurityCheck(); ... } }
public void checkPackageDefinition(String pkg);
このメソッドは修正されました。最初に、
java.security.Security.getProperty("package.definition")を呼び出してコンマで区切られたリストを取得することにより、制限付きのパッケージのリストを得ます。次に、pkgが制限付きパッケージのどれかで開始するかどうか、または等しいかどうかをチェックします。該当する場合には、checkPermissionがRuntimePermission("defineClassInPackage."+pkg)アクセス権で呼び出されます。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドの 1 行目で、
super.checkPackageDefinitionへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkPackageDefinition(String pkg) { super.checkPackageDefinition(pkg); ... someCustomSecurityCheck(); ... } }
public void checkSetFactory();
このメソッドは修正されました。
checkPermissionをRuntimePermission("setFactory")アクセス権で呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkSetFactoryへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkSetFactory() { if (someCustomSecurityCheckFails()) { super.checkSetFactory(); } } }
public void checkMemberAccess(Class clazz, int which);
このメソッドは修正されました。デフォルトのポリシーは PUBLIC メンバへのアクセスおよび、呼び出し元と同じクラスローダを持つクラスへのアクセスを許可します。それ以外の場合はすべて、
checkPermissionがRuntimePermission("accessDeclaredMembers")アクセス権で呼び出されます。このメソッドをオーバーライドする場合は、
super.checkMemberAccessへの呼び出しは行えません。checkMemberAccessのデフォルト実装は、スタック深度 4 にあることをチェックされるコードに依存します。次に例を示します。someCaller[3] java.lang.Class.someReflectionAPI [2] java.lang.Class.checkMemberAccess [1] SecurityManager.checkMemberAccess [0]この動作をエミュレートするには、getClassContextを呼び出し、デフォルトのcheckMemberAccessメソッドの場合と同様に、インデックス 3 のクラスのクラスローダを調べる必要があります。if (which != Member.PUBLIC) { Class stack[] = getClassContext(); /* * stack depth of 4 should be the caller of one of the * methods in java.lang.Class that invoke checkMember * access.The stack should look like: * * someCaller [3] * java.lang.Class.someReflectionAPI [2] * java.lang.Class.checkMemberAccess [1] * MySecurityManager.checkMemberAccess [0] * */ if ((stack.length<4) || (stack[3].getClassLoader() != clazz.getClassLoader())) { if (checkMemberAccessPermission == null) checkMemberAccessPermission = new RuntimePermission("accessDeclaredMembers"); checkPermission(checkMemberAccessPermission); } }このメソッドは、JDK で現在でも呼び出し元の深度に基づいている唯一のセキュリティマネージャメソッドです。このメソッドが存在する理由は、呼び出し元が、自分と同じクラスローダからのクラスに反映できるようにするためです。
public void checkSecurityAccess(String target);
このメソッドは修正されました。指定されたアクセス権ターゲット名に対する
SecurityPermissionオブジェクトを作成し、そのアクセス権でcheckPermissionを呼び出します。このメソッドをオーバーライドする場合は、オーバーライドされたメソッドが通常は例外をスローする位置で、
super.checkSecurityAccessへの呼び出しを行う必要があります。次に例を示します。public class MySecurityManager extends SecurityManager { public void checkSecurityAccess(String target) { if (someCustomSecurityCheckFails()) { super.checkSecurityAccess(target); } } }
public ThreadGroup getThreadGroup();
このメソッドは修正されていません。
|
Copyright © 1997-2001 Sun Microsystems, Inc.All Rights Reserved. コメントの送付先: java-security@sun.com。これは購読リストではありません。 |
 Java ソフトウェア |