Applets opening sockets using Java Plug-in 1.1 on WinNT with IE4

devnull@ad1440.net
Wed, 1 Jul 1998 21:25:00 -0700 (PDT)

From: devnull@ad1440.net
Date: Wed, 1 Jul 1998 21:25:00 -0700 (PDT)
To: Seattle Java Users Group <seajug@rit.com>,
Subject: Applets opening sockets using Java Plug-in 1.1 on WinNT with IE4

I have an applet that opens a socket on port 162 to listen for
SNMP traps. In order to use this, users usually have to disable applet
security for this in their browser. Recently (yesterday), we started
using the Java Plug-in to get our product working on Netscape, etc. since
we use JDK1.1.x
The plug-in seems to have it's own security system which
essentially bypasses the browser's built-in security so that any settings
on the browser no longer apply to the applet. In order to work around
this, I decided to use the signing features available with javakey, etc.
even though this requires users to either have their own javakey program
or to download a file called identitydb.obj into their home directory
(possibly blowing away other files of same name that they downloaded for
other trusted applets, or vice versa and thereby causing great headaches
to users and programmers alike). It seems that this is the only way to
get around security features that the plug-in has.
So far so good. I'm not too upset by this because I've been
meaning to get around to signing my applet sooner or later anyway, and at
the same time, it required me to go to a jar file format, which is
inherently better anyway. So the tradeoffs are slightly in favor of doing
this anyway.
Well, lo and behold, the applet runs under netscape without a
hitch. Once the user puts the correct identitydb.obj file in their home
directory and does the plug-in FAQ's workaround bug of setting the plugin
arguments to have
-Dappletviewer.security.mode=unrestricted
(a large hole, but they say they'll fix in next version of plugin, so I
have to live with it...*grumble* *gripe*).
HOWEVER, under IE, in which my applet used to work (albeit with
some major bugs -- which is why we are going to the plug-in, to provide a
consistent JVM across platforms), it now generates a security exception
when the SNMP library tries to open a socket to listen on port 162.

sun.applet.AppletSecurityException: checkListen
at java.lang.Throwable..<init> (Compiled Code)
at java.lang.SecurityException.<init> (Compiled Code)
at sun.applet.AppletSecurityException.<init> (Compiled Code)
at sun.applet.AppletSecurityException.<init> (Compiled Code)
at sun.applet.AppletSecurity.checkListen(AppletSecurity.java:480)
at java.net.DatagramSocket.create(DatagramSocket.java:125)
at java.net.DatagramSocket.<init>(DatagramSocket.java:114)
at java.net.DatagramSocket.<init>(DatagramSocket.java:125)
at Snmp.SnmpSession.open(SnmpSession.java:137)
at WebCNM.TrapListener.init (Compiled Code)
at WebCNM.Webnms.init (Compiled Code)
at sun.applet.AppletPanel.run (Compiled Code)
at java.lang.Thread.run (Compiled Code)

Well, that's sort of fine -- at least I know the Security Manager
is doing it's job. However, for other such problems, there are ways to
have the user disable these security features. For example, to allow them
to write to files, I would simply tell them to put
-Dacl.write=/ in their plug-in parameters line (or the NT equivalent if
theyre on NT).
After exhaustive searching through FAQ's, etc, I cannot find a way
to disable the part of the security manager that controls the ports a user
can listen on.
What's even more frustrating is that this problem only occurs on
IE. (although I haven't yet tested Netscape on PC's, I have tested it on
Solaris, and it does not have this problem -- it freely opens the SNMP
trap port with nary a quibble as long as my applet is signed and
"trusted". The same behavior with appletviewer and HotJava (on
Solaris). I'm about to try it with netscape on the PC to determine if
this is a plugin platform difference or whether this is due to just IE).
I'm not sure whether this security is intentional or overlooked,
but I think that if my applet is trusted, it should be able to do what it
wishes. If that is not to be policy, then whatever policy it ends up
being should be consistent across platforms. In addition, there should be
a documented way to override parts of the Security Manager, such as there
is for acl.write and acl.read and system properties. I suspect that a
simple flag DOES exist to allow me to get past this, but I cant find it
documented anywhere.

If anyone knows of this elusive flag to allow applets to bypass
the checkListen method and listen on socket port 162, please tell me. At
this point, I'm desperate.

Thanks greatly in advance.

==============================================================================
lwilson@bridgeway.com S/W Developer http://www.bridgeway.com
devnull@ad1440.net Webmaster http://www.ad1440.net/~devnull
==============================================================================
Don't Anthropomorphize Computers -- They Really Hate That...