[JavaHouse-Brewers:18502] Re: RMIのプログラムでNaming.rebind(nam e,this)で例外
owner-ja...@java-house.etl.go.jp
原因は、新セキュリティモデルの導入です。
RMI だけではなく、様々なコード、人が影響を受けるはずです…
Almaak さん wrote:
Almaak> 興味があってRMIを調べているところです。
Almaak> windows95 ＪＤＫ１．２ ｂｅｔａ４で、RMIサンプルプログラム（※１）
Almaak> ＜エラーの内容＞
Almaak> access denied (java.net.SocketPermission 127.0.0.1:1099
Almaak> connect,resolve)
JDK 1.2 では新しいセキュリティモデルが導入されます。
1.2 Beta は、Beta 4 *から*、新モデルに基づいた実装になりました。
もはや、CLASSPATH 中のクラスだからといって何でも出来るわけではありません。
詳しくは、JDK 1.2 Beta 4 ドキュメント中の
jdk1.2beta4/docs/guide/security/index.html
をお読み下さい。
ちなみに、ドキュメントは JDK 本体とは別にアーカイブされています。
jdk12-beta4-doc.なんとかです。
では、実際にどうすれば access denied を避けられるのか。
1.2 Beta4 以前の JDK、例えば 1.1.6 を使う、という手もあります。
新モデルとどうつき合って行くかについては、
メイル末尾に RMI-users ML に流れた文章を付けます。
Almaak> まだ初心者なので、変なことが書かれているかもしれません。
足をつっこんでいきなり、
今なお変化を続けている部分にぶつかってしまったわけですね。
後愁傷さまなのか、よい経験なのか…
SHUDO Kazuyuki/首藤一幸 私をたばねないで あらせいとうの花のように
shu...@muraoka.info.waseda.ac.jp
RMI-users のメイルひとつめ
=====
Message-ID: <95851524.f...@three.serpentine.com>
Date: Wed, 22 Jul 1998 21:50:50 -0400
Reply-To: Adrian Colley <Adrian...@East.Sun.COM>
From: Adrian Colley <Adrian...@East.Sun.COM>
Subject: Re: RMI binding broken on 1.2b4
j> Er, hold up a second. What this implies is that you cannot just say,
j> 'here, run this class right here' without having to specifically
j> enable all kinds of security and permissions policies if you want it
j> not to be in a sandbox every bit as restrictive as the 1.1 applet
j> sandbox, doesn't it?
Right. The class you run is unprivileged unless you grant it some
privileges. Until 1.2b4, CLASSPATH classes were unrestricted, which
isn't a terribly bright idea (hands up everyone who runs their
everyday processes as root). JDK1.2 reserves system privileges for
the bootclasspath classes (i.e. the JDK) and hands out minimal
permission to everything else.
You can say: java -Djava.security.policy=policyfile SomeClass
to apply the file "policyfile".
There are some permissions allocated by default: they're in the
jdk1.2beta4/jre/lib/security/java.policy file (you can edit this file
to grant more permissions on a systemwide basis).
One idiom which I expect many people will use grants full privileges
to code loaded from a certain codebase:
grant codeBase "file:/jini/files/sandbox/aecolley/lib/classes/" {
permission java.security.AllPermission;
};
(don't do this with non-local file: codebases!)
j> This can't be true, can it? My server was able to read and write
j> files on the local disk with no trouble, without my having to do
j> something special to mark those classes as trusted.. it looks as
j> though up until the point where I specifically set a security manager,
j> I was living in the land of the free and risky, just like in good 'ol
j> 1.1.
Well, the price of security is eternal permissions checking. Now you
can know that your server can't be tricked into reading /etc/passwd
and sending it out to the world. (Don't panic, I made this up.)
j> I can see the JDC articles trying to explain all of this now. ;-)
Yes, it annoyed the hell out of me until I figured out how to work
with it. Here's a hint: java -Djava.security.debug=help foo.
--adrian.
RMI Team
=====
RMI-users のメイルふたつめ
=====
Message-ID: <C15B661A10DBD11181F...@mail.intranet>
Date: Tue, 4 Aug 1998 11:19:04 +1200
From: Kevin Wells <Ke...@INTRAHEALTH.CO.NZ>
Subject: Re: java.security.AccessControlException
I assume you are using JDK 1.2 beta 4. A new security model was
introduced in this version of the JDK. When you set a security manager
in your server application this causes security to be enforced for the
application just as security is normally enforced for applets. Consider
the following example program (in a file called Test2.java):
import java.net.InetAddress;
import java.rmi.RMISecurityManager;
public class Test2 {
public static void main( String args[] ) {
try {
InetAddress address = InetAddress.getByName( "boxster" );
System.out.println( address.toString() );
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
address = InetAddress.getByName( "boxster" );
System.out.println( address.toString() );
} catch (Exception e) {
System.out.println("Test: " + e.getMessage());
e.printStackTrace();
}
}
}
The output produced is as follows:
E:\projects\test> java Test2
boxster/192.168.0.108
Test: access denied (java.net.SocketPermission boxster resolve)
java.security.AccessControlException: access denied
(java.net.SocketPermission b
oxster resolve)
at java.security.AccessControlContext.checkPermission(Compiled
Code)
at
java.security.AccessController.checkPermission(AccessController.java:
442)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:437)
at
java.lang.SecurityManager.checkConnect(SecurityManager.java:795)
at java.net.InetAddress.getAllByName0(Compiled Code)
at java.net.InetAddress.getAllByName0(InetAddress.java:524)
at java.net.InetAddress.getByName(Compiled Code)
at Test2.main(Test2.java:14)
The first call successfully resolves the address of my machine (boxster)
using DNS. The second call fails because a security manager is installed
and the application is not allowed to connect to a socket. If the same
program is run with a security policy file then the output is as
follows:
E:\projects\test>java -Djava.security.policy=test.policy Test2
boxster/192.168.0.108
boxster/192.168.0.108
Where the test.policy file is as follows:
grant {
// Allow everything for now
permission java.security.AllPermission;
};
SUMMARY
Because an RMI Server uses a security manager a policy file must be
specified so that the application has permission to open a socket or to
resolve an address.
I found that a security policy was necessary for both the "rmiregistry"
and for the "hello server". This is contrary to the Hello World example
in the RMI Guide supplied with JDK 1.2 beta 4. The example suggests that
policy only needs to be specified for the rmiregistry.
Note that a policy file can be placed in you home directory and will
then apply to all applications that you run. See the JDK documentation
for more information.
Hope this helps.
[Ignore my previous mailing list question. I read about SET RMI-USERS
REPRO].
Kevin Wells
Ethos Software Architects Ltd
=====