[3344] in java-interest
Returned mail: Cannot send message for 1 hour
daemon@ATHENA.MIT.EDU (Mail Delivery Subsystem)
Wed Nov 8 08:24:39 1995
Date: Wed, 8 Nov 95 10:53:21 CST
From: Mail Delivery Subsystem <mailer-daemon@hic334.decnet.bosch.de>
To: "java-interest@java.sun.com"@si4919.DECNET.bosch.de
Apparently-To: si4919::java-interest@java.sun.com
----- Transcript of session follows -----
421 hi02c342: Host hi02c342 is down
----- Unsent message follows -----
Received: by HI02C334. (5.0/SMI-SVR4-DNI-8.0)
id AA29601; Wed, 8 Nov 1995 09:55:47 --100
Received: by DniMail (8.0Beta1); Wed, 8 Nov 95 09:55:42 MET
From: SI4919::java-interest@java.sun.com (MAIL-11 Daemon)
To: HIC334::java-interest-digest@java.sun.com
Subject: java-interest-digest V1 #252
content-length: 0
java-interest-digest Monday, 6 November 1995 Volume 01 : Number 252
In this issue:
re:abstract methods
Getting Security Exception
arrays of instances of objects
Re: I want to shoot myself!!!!!!!!!!!!!!!!!!
PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
Re: Beta Win95 JDK appletviewer crawls on startup?
[none]
Definitions, Macros?
Re: Why are dll's in bin?
Re: Beta Win95 JDK appletviewer crawls on startup?
Re: Type and Overload resolution
Java insecurity - long - argumentative - you are warned. (fwd)
Re: a question about structures
Re: arrays of instances of objects
Re: arrays of instances of objects
Loading a URL from an applet
----------------------------------------------------------------------
From: "andrew (a.) francis" <andrewfr@bnr.ca>
Date: Mon, 6 Nov 1995 07:02:00 -0500
Subject: re:abstract methods
In message "abstract methods", you write:
> The java spec section 4.10.5 says that abstract methods cannot contain
> a body. Why is this restriction made?
If the all the methods of abstract classes had method bodies, I don't
understand why one would want abstract classes in the first place?
(note: I believe the new Java language spec needs the keyword "abstract"
to make a method abstract)
> There are plenty of situations where it makes sense to have an abstract
> method which also supplies a default body. In particular, for methods
> where the behavior is to call the superclass' method, then append semantics
> for the subclass.
Couldn't the same effect be achieved by having a normal base class and
have sub-classes override the methods it is interested in changing, and in
the process, make calls to the overridden superclass method via the
super variable? Or if you do not want the pseudo-abstract class instantiated,
couldn't you make its constructors protected?
> One may well want these types of functions abstract to force conformance
> to some "well-formed-object" spec which allows objects to work in some
> debug environment, builder environment, etc.
Cheers,
Andrew Francis
------------------------------
From: dstrauss@panix.com (David Strauss)
Date: Mon, 06 Nov 95 06:57:54
Subject: Getting Security Exception
I am attempting to run the Fractal demo applet that comes with
the beta JDK (I'm running Windows 95) by loading an HTML file
into the Applet Viewer from a different directory than /java/demo/Fractal,
where the applet's classes are stored. I am modifying the example1.html
that comes with it by adding the codebase attribute as follows:
<applet codebase="file:/c:/Java/demo/Fractal"
code="CLSFractal.class" width=500 height=120>
I save this mod in a different directory, load it into the Applet
Viewer and get the following output:
[no properties loaded, using defaults]
Thread-1 find class CLSFractal
Opening stream to: file:/c:/Java/demo/Fractal/CLSFractal.class to get
CLSFractal
status: applet loaded
Thread-1 find class ContextLSystem
Opening stream to: file:/c:/Java/demo/Fractal/ContextLSystem.class to get
ContextLSystem
*** Security Exception: file.read:\c:\Java\demo\Fractal\ContextLSystem.class
***
sun.applet.AppletSecurityException: security.file.read:
\c:\Java\demo\Fractal\ContextLSystem.class
at sun.applet.AppletSecurity.checkRead(AppletSecurity.java:226)
at java.io.FileInputStream.<init>(FileInputStream.java:49)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:67)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.j
ava:74)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:65)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:160)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:122)
at java.awt.Component.resize(Component.java:451)
at sun.applet.AppletPanel.run(AppletPanel.java:275)
at java.lang.Thread.run(Thread.java:286)
Thus, it seems to have no problem finding and loading the CLSFractal
class but chokes on ContextLSystem, which is in the same directory.
Incidentally, loading the original example1.html from the Fractal
directory works fine.
What do I need to know about security restrictions that I don't?
- ------------------------------------------------
David Strauss
E-mail: dstrauss@popserver.panix.com
dstrauss@lehman.com
- -------------------------------------------------
------------------------------
From: nrc2 <nrc2@aber.ac.uk>
Date: Mon, 06 Nov 1995 11:44:17 +0000
Subject: arrays of instances of objects
I'm having trouble defining an array of instances of objects
I have a class called TreeNode that is a node of a Binary Tree and I
want to declare an array of instances of this. I've tried
TreeNode Tree[] = new TreeNode[16];
but this seems to declare an array of null pointers.
Thanks.
Neil
------------------------------
From: arnold@cocolat.East.Sun.COM (Ken Arnold - Sun Labs)
Date: Mon, 6 Nov 1995 10:25:07 -0500
Subject: Re: I want to shoot myself!!!!!!!!!!!!!!!!!!
What you get from declaring something as a RuntimeException is the
ability to throw it without declaring that you do so. In other words,
it is a way to *not* document what you throw. When is this good?
Well, when is it ever good to avoid documenting a method's behavior?
The answer is essentially "hardly ever". Arthur's "everyone does it,
and everyone knows that everyone does it" exception is the only valid
out, as long as everyone *means* everyone.
Arthur's point is well taken if it is taken carefully. You would be
hard pressed to find exceptions you have just discovered that could
happen, say, in OutputStream.write(). So if you cut yourself enough
slack to extend RuntimeException somewhere, you are probably cutting
enough extra slack to hang yourself.
You have already seen the danger in the "I don't need to catch it"
approach -- you suggested MalformedRegexp as a good example of it, and
it isn't. David Foster pointed out that it depends where the regexp
came from. In other words "some need to, some don't". The ones who
need to catch it need to know you throw it, so you should put it in
your throws clause and not extend RuntimeException for it.
Edith Au said it right: you extend RuntimeException when you are
creating an error in the virtual machine runtime. Which you probably
aren't. Otherwise you should extend Exception.
Ken Arnold
------------------------------
From: sameer <sameer@c2.org>
Date: Mon, 6 Nov 1995 07:53:09 -0800 (PST)
Subject: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
For Immediate Release
Date: Nov 6th, 1995
Contact: Sameer Parekh 510-601-9777 sameer@c2.org
PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
Two Princeton University grad students, Dan Wallach and Drew Dean,
recently discovered holes in Sun Microsystem's HotJava web browser. In
response to this finding, Community ConneXion, well known for offering
rewards for exposing holes in internet security products, has decided
to award them with a t-shirt and expand the Community ConneXion Hack
line of promotions to include Java and Java-related products.
Sun's Java product is alleged to allow people browsing the
World-Wide-Web to execute programs on their own computers without
worrying about whether or not the programs were viruses or not. The
holes Wallach and Dean found show that there are a few things in the
HotJava alpha implementation of the Java language which make viruses
and other malicious programs possible within the alpha HotJava
web browser.
"We were very impressed with the HotJava concept, so we thought it
would be good to poke around their implementation," said Wallach.
"While we did find some interesting holes, we believe these can be
addressed and Java could make a good standard for remote code on the
Web, if an effective security policy is defined."
Wallach and Dean released their findings initially in the RISKS
Digest, and plan to publish a paper detailing their results. The holes
they found make it possible for a malicious applet to set things up so
as to be able to monitor or modify all of a given web-surfer's
activity, after they ran the malicious applet exploiting the holes. By
doing so the applet may make it possible to violate user's privacy by
revealing to an third party their web traffic.
The holes they found exist only in the alpha release of HotJava. The
beta release, which is the version found in the widely-used Netscape
Navigator 2.0b1J is not vulnerable to these attacks.
"I don't want to be in the t-shirt business," said Sameer Parekh,
President of Community ConneXion, "but we felt that these students'
work deserved a t-shirt. Java has great potential for making the
Internet much more powerful than it already is. It is very important
that we examine Java and make sure that we can trust it." Community
ConneXion, in addition to this Hack Java t-shirt promotion, is
offering t-shirts to people who find holes in Netscape, Microsoft, and
DigiCash.
Information about the Hack Java promotion is available from
http://www.c2.org/hackjava/.
Community ConneXion is the premier internet privacy ISP. They offer
anonymous accounts, remailers, and psuedonym servers, in addition to
the standard ISP fare of webspace and dialup IP access. Information is
available from http://www.c2.org/ or from sending email to
info@c2.org.
Java and HotJava are trademarks of Sun Microsystems, Inc. Netscape and
Netscape Navigator are trademarks of Netscape Communications
Corporation. The Hack Java promotion is not affiliated with nor
sponsored by Sun Microsystems.
------------------------------
From: jonathan@athenanow.com (Jonathan Taylor)
Date: Mon, 6 Nov 1995 11:06:19 -0400
Subject: Re: Beta Win95 JDK appletviewer crawls on startup?
At 03:26 PM 11/5/95 -0700, you wrote:
>On Win95, JDK Beta:
>
>Attempting to run the appletviewer:
>
> (cd ...\java)
> bin\appletviewer demo\GraphLayout\example1.html
>
>results in the appletviewer window appearng (empty) except for the
>menubar with the "Applet" button; and text in the lower left corner
>which says "starting applet..."
>
I've had the same experience, except that initializing the network interface
before launching the Applet Viewer works for me. Evidently, the Applet
Viewer makes network calls even when working with local files. (Which makes
development on a laptop difficult.)
------------------------------
From: Alexander Douglas Culp <axorth@cs.utexas.edu>
Date: Mon, 6 Nov 1995 10:51:45 -0600 (CST)
Subject: [none]
request
------------------------------
From: Joseph.Wishner@West.Sun.COM (Joseph Wishner SunSoft ENP 206-889-1343)
Date: Mon, 6 Nov 1995 10:41:16 -0800
Subject: Definitions, Macros?
Hello. How do I get equivalent functionality to C++ definitions so that
I can give meaming to datatypes, like enums, #defines, etc? I do have
the language guide, but where it doesn't help is in pointing out key differences
with other languages.
After programming for many years in C and C++, this is my major sumbling block
to designing a Java language program and understand how to use java in general.
For example:
enum (DOWN, UP, BOOTING)
or:
#define TIMEOUT 10
I am not on this alias, so please respond directly to me.
Much obliged,
Joseph
------------------------------
From: tball@scndprsn.Eng.Sun.COM (Thomas Ball)
Date: Mon, 6 Nov 1995 11:31:52 -0800
Subject: Re: Why are dll's in bin?
Ask Microsoft -- DLL's are looked up with the PATH variable, not a separate
library list like Solaris' LD_LIBRARY_PATH. The rule for finding DLL's is
(true for all Windows apps): same directory as .exe, Windows directory,
Windows system directory, then PATH.
Tom Ball
Java Products Group
> From daemon@java Fri Nov 3 20:38:21 1995
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: Why are dll's in bin?
> To: java-interest@java
> X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
>
> Why are the dynamic libraries distributed in ../bin and not ../lib?
>
> Gary Aitken garya@village.org
> -
> This message was sent to the java-interest mailing list
> Info: send 'help' to java-interest-request@java.sun.com
------------------------------
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
Date: Mon, 6 Nov 1995 11:44:32 -0800
Subject: Re: Beta Win95 JDK appletviewer crawls on startup?
> On Win95, JDK Beta:
>
> Attempting to run the appletviewer:
>
> (cd ...\java)
> bin\appletviewer demo\GraphLayout\example1.html
>
> results in the appletviewer window appearng (empty) except for the
> menubar with the "Applet" button; and text in the lower left corner
> which says "starting applet..."
>
> If you choose "Quit" or click the close glyph in the wm title bar,
> it exits; choosing any other menu item does nothing, and subsequently
> Quit does not work either (presumably it is blocked pending the previously
> requested action).
>
> After a long wait (a minute?), the messages
> "status: applet loaded"
> "status: applet initialized"
> "status: applet started"
> appear in the DOS window from which it was started;
> the lower left corner label in the viewer changes to "applet started";
> and the applet appears.
>
> What's going on?
> Is some network connection probe being attempted?
> (no network connection was available in this case, but making one
> available seemed to make no difference)
As part of initializing Java, the Java network library attempts to make
a WINSOCK connection. If it's not available, it will timeout. If you
have MSN set up, just click the cancel button when the dialer dialog
comes up.
> Aside: Do 2.0 Navigator and Java still require Microsoft's winsock, or will
> a Trumpet winsock work as well?
Any WINSOCK compliant product should work, but we can't help anyone set
it up correctly.
> BTW, some of the demos, such as BarChart, do not work properly unless
> run from their subdirectory.
That's a known problem with file URLs (we're working on it). You won't
see this if accessing the samples from an HTTP server.
> BTW, changing the properties does not save correctly as distributed;
> the subdirectory java\.hotjava does not exist in the distribution.
> Once created, they save fine.
We hope to have a true setup.exe in the 1.0 release for the Win32 port.
One of the things it will do is create this directory.
Tom Ball
Java Products Group
------------------------------
From: arnold@cocolat.East.Sun.COM (Ken Arnold - Sun Labs)
Date: Mon, 6 Nov 1995 14:45:22 -0500
Subject: Re: Type and Overload resolution
Yuan Jiang asks:
>I thought Java enforces types strictly. Then I'm confused with the
>method (or the smae name and number of parameters) overload resolution
>scheme:
>
>It uses a parameter-type conversion cost table to determine "which
>matching method has the lowest type conversion cost."
This document (the alpha language spec) is out of date. It is still a
good starting point, but things have changed. This is one of them.
The matching is now done by a "most exact match" strategy, not by
counting conversion cost.
Ken
------------------------------
From: Aleph One <aleph1@dfw.net>
Date: Mon, 6 Nov 1995 13:56:30 -0600 (CST)
Subject: Java insecurity - long - argumentative - you are warned. (fwd)
If one of sun's people have some free time they might want to get this guy
straigth.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
- ---------- Forwarded message ----------
Date: Mon, 6 Nov 1995 05:47:35 -0500 (EST)
From: Dr. Frederick B. Cohen <fc@all.net>
To: cypherpunks@toad.com
Subject: Java insecurity - long - argumentative - you are warned.
WARNING - THIS MESSAGE CONTAINS INFORMATION THAT MIGHT BE CONSIDERED AS
A FLAME BY SOME READERS - IT IS LONG AND TEDIOUS - YOU ARE WARNED!
>From the Java Web pages (as combined in Firewalls/BoS):
> The language's security features (not just applets):
>
> (http://java.sun.com/whitePaper/javawhitepaper_6.html#HEADING15)
>
> 4.2 Security in the Java Environment
>
> Security commands a high premium in the growing use of the Internet
> for products and services ranging from electronic distribution of
> software and multimedia content, to "digital cash". The area of
> security with which we're concerned here is how the Java compiler and
> run-time system restrict application programmers from creating
> subversive code.
But not non-subversive code? Sounds like a value judgement to me.
Subversive code is not otherwise defined in these documents.
> The Java language compiler and run-time system implement several
> layers of defense against potentially incorrect code.
Is incorrect code subversive? Vica versa? Does Java provide defenses
against my code not properly calculating numbers?
> One of the Java
> compiler's primary lines of defense is its memory allocation and
> reference model. Simply put, Java does not have "pointers" in the
> traditional C and C++ sense--memory cells that contain the addresses
> of other memory cells.
>
> Memory layout decisions are not made by the compiler, as they are in C
> and C++. Rather, memory layout is deferred to run-time, and will
> potentially differ depending on the characteristics of the hardware
> and software platforms on which the Java language system is
> executing. The Java interpreter references memory via symbolic
> "handles" that are resolved to real memory addresses at run time. Java
> programmers can't forge pointers to memory, because the memory
> allocation and referencing model is completely opaque to the
> programmer and controlled entirely by the underlying run-time system.
Just because it is opaque, doesn't mean you can't happen across a valid
(but perhaps undesirable) handle. Sounds like a good issue for attack
by crypto-types. How do we guess the handle of the disk IO routines?
> Very late binding of structures to memory means that programmers can't
> infer the physical memory layout of a class by looking at its
> declaration. By removing the C/C++ memory layout and pointer models,
> the Java language has eliminated the programmer's ability to get
> behind the scenes and manufacture pointers to memory. These features
> must be viewed as positive benefits rather than a restriction on the
> programmer, because they ultimately lead to more reliable and secure
> applications.
Is the language un-predictable? The same program executes differently
each time? A pseudo-random allocation? What is the technique used to
implement this, and why should we believe it is in fact secure in some
sense. And if so, in what sense?
> The Byte Code Verification Process
>
> What about the concept of a "hostile compiler"? Although the Java
> compiler ensures that Java source code doesn't violate the safety
> rules,
What are these "safety rules"? No reference to them in this document!
> when an application such as the HotJava web browser imports a
> code fragment from anywhere, it doesn't actually know if code
> fragments follow the Java language rules for safety--the code may not
> have been produced by a known-to-be trustworthy Java compiler. In such
> a case, how is the Java run-time system on your machine to trust the
> incoming byte code stream? The answer is simple--it doesn't trust the
> incoming code, but subjects it to byte code verification.
>
> The tests range from simple verification that the format of a code
> fragment is correct, to passing through a simple theorem prover to
> establish that the code fragment plays by the rules--that it doesn't
> forge pointers, it doesn't violate access restrictions, and it
> accesses objects as what they are (for example, that "InputStream"
> objects are always used as "InputStreams" and never as anything
> else). A language that is safe, plus run-time verification of
> generated code, establishes a base set of guarantees that interfaces
> cannot be violated.
Wait a minute. If it's so safe, what code can possibly be sent in that
would cause a violation? If the prover is so simple, how can it show
things (e.g., program correctness) in real-time on a PC that the rest of
the world can't show with supercomputers over extended periods? What
EXACTLY are these things doing, and why should we believe they are safe?
> The Byte Code Verifier
>
> The last phase of the byte code loader is the verifier. It traverses
> the byte codes, constructs the type state information, and verifies
> the types of the parameters to all the byte code instructions.
> The illustration [see the HTML] shows the flow of data and control
> from Java language source code through the Java compiler, to the byte
> code verifier and hence on to the Java interpreter. The important
> issue is that the Java class loader and the byte code verifier make no
> assumptions about the primary source of the byte code stream--the code
> may have come from the local system, or it may have travelled halfway
> around the planet. The byte code verifier acts as a sort of
> gatekeeper. The byte code verifier ensures that the code passed to the
> Java interpreter is in a fit state to be executed and can run without
> fear of breaking the Java interpreter.
So there are byte code sequences that can break the interpreter!
> Imported code is not allowed to
> execute by any means until after it has passed the verifier's
> tests. Once the verifier is done, a number of important properties are
> known:
>
> There are no operand stack overflows or underflows
Not so easily proven, is it?
> The types of the parameters of all byte code instructions are
> known to always be correct
Huh? I thought you couldn't have incorrect types. Do they mean that you
can have incorrect types but that they are detected by the verifier at
load time?
> No illegal data conversions are done, like converting integers
> to pointers
How about legal ones - like converting integers to pointers via case
statements?
> Object field accesses are known to be legal--private or public
> or protected
What exactly does this mean?
> While all this checking appears excruciatingly detailed, by the time
> the byte code verifier has done its work, the Java interpreter can
> proceed knowing that the code will run securely. Knowing these
> properties makes the Java interpreter much faster, because it doesn't
> have to check anything. There are no operand type checks and no stack
> overflow checks. The interpreter can thus function at full speed
> without compromising reliability.
Can computers actually "know" anything?
No runtime checking whatsoever. Get past the supposed verifier, and you
have free run of the machine. A single verifier bug or inadequacy, and
the world is unsafe for electronic commerce. And has the Java code been
verified to prove the claimed properties? Against what criteria? Where's
the beef?
> Security Checks in the Class Loader
>
> After incoming code has been vetted and determined clean by the byte
> code verifier, the next line of defense is the Java class loader. The
> environment seen by a thread of execution running Java byte codes can
> be visualized as a set of classes partitioned into separate name
> spaces. There is one name space for classes that come from the local
> file system, and a separate name space for each network source.
>
> When a class is imported from across the network it is placed into the
> private name space associated with its origin. When a class references
> another class, it is first looked for in the name space for the local
> system (built-in classes), then in the name space of the referencing
> class. There is no way that an imported class can "spoof" a built-in
> class. Built-in classes can never accidentally reference classes in
> imported name spaces--they can only reference such classes
> explicitly. Similarly, classes imported from different places are
> separated from each other.
But they can explicitly reference each other? I can only explicitly open
a file called command.com on your PC?
> Security in the Java Networking Package
>
> Java's networking package provides the interfaces to handle the
> various network protocols (FTP, HTTP, Telnet, and so on). This is your
> front line of defense at the network interface level. The networking
> package can be set up with configurable levels of paranoia. You can:
>
> Disallow all network accesses
>
> Allow all network accesses
>
> Allow network accesses to only the hosts from which the code was
> imported
>
> Allow network accesses only outside the firewall if the code
> came from outside
Who wants to bet that 99+% of all users configure "Allow all network
accesses". Hot Java today is defaulted to this state.
> Applet-specific security: (written for the 1.0a3 release of
> HotJava(tm)... there will be a rewrite for the 1.0b release when that
> occurs. I'm assuming, perhaps incorrectly, that the Netscape
> implementation is similar. As I understand it, they licensed the HJ
> code from Sun, so I think it's all very close to the truth.)
>
> (http://java.sun.com/1.0alpha3/doc/security/security.html)
>
> [ A rehash of the above text, snipped ]
>
> Security level four: protecting the file system and network access
>
> HotJava enforces security policies confident that its security
> interfaces are secure.
In other words, it assumes the other three levels worked properly.
If they don't, you're screwed.
> The three lower levels of security guarantee
> that all local classes, e.g., the file access primitives, are
> themselves protected from being supplanted, replaced, or extended by
> imported code.
You're screwed.
> The file access primitives implement an access control list that
> controls read and write access to files by imported code (or code
> invoked by imported code). The defaults for these access control lists
> are very restrictive[*]. If an attempt is made by a piece of imported
> code to access a file to which access has not been granted, a dialog
> box pops up to allow the user to decide whether or not to allow that
> specific access. These security policies err on the conservative side
> in order to ensure maximum security. This conservative approach may
> make writing some applets more difficult or awkward.
By default - ask the user. That's restrictive? Please press the OK
button to have our free Lotus update loaded into your computer.
> For network security, HotJava provides a variety of mechanisms that
> can provide information about the trustworthiness of imported
> code. These mechanisms cover a wide range of possibilities. At the
> simple end the system can check on the origin of a code fragment to
> determine if it came from inside or outside a firewall. At the
> sophisticated end of the range a mechanism exists whereby public keys
> and cryptographic message digests can be securely attached to code
> fragments that not only identify who originated the code, but
> guarantee its integrity as well. This latter mechanism will be
> implemented in future releases.
So today, if the admin specifies the proper IP address ranges when
loading Java into each computer in the network, and if no user ever
installs Java on their own, "code" downloads from external machines
may be stopped - unless the user says OK.
> The security policies implemented by the runtime system can be
> dynamically adjusted based on the information available concerning the
> origin of a code fragment. The Socket class provides such an example.
>
> The Socket class implements security policies that are adjusted to
> reflect the trustworthiness of the code that invoked it, and
> transitively, the code that invoked the invoker. The information about
> what code began the chain of execution is available to the class in
> the form of which namespace contains the invoking code and what
> parameters are associated with that class. The class loader puts the
> classes it has loaded in a specific namespace, allowing the Socket
> class to determine the network host from which a class is loaded.
>
> Knowing the network host allows the HotJava security mechanism to
> determine whether the class originated inside or outside a
> firewall. Knowledgable users of HotJava can decide which category of
> hosts to trust when loading executable code.
How about the more than 99.99% of users who are not knowledgable of HotJava?
> For example, the Socket
> class can implement the policy of only allowing new connections to be
> created that terminate at the host from whence the code was
> loaded. This restriction means that code loaded from outside a
> firewall cannot connect to other machines on the net behind the
> firewall.
Unless that machine acts as a gateway for further processing.
> Code that comes from more trusted sources can be allowed
> more freedom to make connections to other machines. As an additional
> defense against untrusted sources HotJava's security can be set to
> prevent any code from being loaded. The level of security is
> configurable by HotJava users.
The user dictates the security policy. Any user in your site can
potentially, through error or omission or intent, open up a hole to your
entire network by accidentally pressing the OK button one time or by
setting a configuration parameter incorrectly. And your firewall will
not save you.
ASBESTOS SUITS MAY NOW BE REMOVED - FLAME OFF.
P.S.
When: Tuesday, November 7, 8AM
Where: The Hilton, Washington D.C. (the CSI conference)
The talk: 50 Ways to Attack Your World Wide Web Systems
If you want a chance to heckle - be there.
- --
- -> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
------------------------------
From: arnold@cocolat.East.Sun.COM (Ken Arnold - Sun Labs)
Date: Mon, 6 Nov 1995 14:53:57 -0500
Subject: Re: a question about structures
michaels@pallas.statenet.com asks:
>I realize that java does not handle structures, so what is the best way
>to handle data when you need something like a C like structure to
>handle the organization of small files that hold specific data. I am
>writing an applet that will need to utilize small file I/O, while being
>able to get to certian parts of the data quickly to perform read and
>writes.
You create a class that has only public data members. That is the
struct equivalent. You create a RandomAccessFile so you can seek
around in the file you want to write them in. You provide readFrom()
and writeTo() methods on your "struct" that take a RandomAccessFile as
a parameter and use the DataInput and DataOutput methods to read/write
the data in your "struct".
For example, something like the following would work:
import java.io.*;
public class Point {
public int x, y;
public void readFrom(RandomAccessFile file) throws IOException {
x = file.readInt();
y = file.readInt();
}
public void writeTo(RandomAccessFile file) throws IOException {
file.writeInt(x);
file.writeInt(y);
}
}
Then you could seek around reading and writing the things into a file.
Alternatively you could rely completely on native methods that used
stdio or posix calls, but, well, to be blunt, *bletch* the above really
won't meet your performance requirements.
Enjoy,
Ken Arnold
------------------------------
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
Date: Mon, 6 Nov 1995 12:02:48 -0800
Subject: Re: arrays of instances of objects
That's right, you still need to initialize it -- this bit me hard when
I first started using Java, and it should be documented better. Since
Java doesn't support the notion of a default constructor, the array
allocator has no way of knowing what constructor to call.
It may seem a bother to have to explicitly initialize each member, but
one of the design principles of Java was to reduce most of C++'s hidden
behaviors in favor of explicit statements. Even if you don't like that
approach, the engineer after you who has to support your code probably
will.
Tom Ball
Java Products Group
- ----- Begin Included Message -----
>From daemon@java Mon Nov 6 06:35:38 1995
To: java-interest@java
Subject: arrays of instances of objects
X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
I'm having trouble defining an array of instances of objects
I have a class called TreeNode that is a node of a Binary Tree and I
want to declare an array of instances of this. I've tried
TreeNode Tree[] = new TreeNode[16];
but this seems to declare an array of null pointers.
Thanks.
Neil
- -
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
- ----- End Included Message -----
------------------------------
From: lemayp@lne.com (Laura Lemay, Killer of Trees)
Date: Mon, 6 Nov 1995 12:57:50 -0800
Subject: Re: arrays of instances of objects
>I have a class called TreeNode that is a node of a Binary Tree and I
>want to declare an array of instances of this. I've tried
>
>TreeNode Tree[] = new TreeNode[16];
>
>but this seems to declare an array of null pointers.
Yup. That's what its supposed to do. You then have to put TreeNode
objects into the array yourself:
Tree[1] = new TreeNode();
Tree[2] = new TreeNode();
etc.
Laura
------------------------------
From: Barbara Walters <sasbbw@unx.sas.com>
Date: Mon, 6 Nov 1995 16:04:31 -0500
Subject: Loading a URL from an applet
I've developed an applet that accepts mouseUp events using the Beta JDK
and Netscape. I'd like to load a particular URL as a result.
How do I tell Netscape I have a URL that I want it to load?
Barbara Walters
------------------------------
End of java-interest-digest V1 #252
***********************************
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: by si4919.si.bosch.de (5.65/fma-120691); id AA01948; Wed, 8 Nov 1995 09:47:36 -060
% Received: by si6624.bosch.de (5.65/rg-150294); id AA07201; Wed, 8 Nov 95 09:52:03 +010
% Received: (from daemon@localhost) by java.sun.com (8.6.12/8.6.12) id PAA27623 for java-interest-recipients; Tue, 7 Nov 1995 15:38:41 -0800
% Received: (from majordom@localhost) by java.sun.com (8.6.12/8.6.12) id OAA22057 for java-interest-outgoing; Tue, 7 Nov 1995 14:00:53 -0800
% From: owner-java-interest-digest@java.sun.com
% Date: Mon, 6 Nov 1995 13:04:29 -0800
% Message-Id: <199511062104.NAA08233@java.sun.com>
% To: java-interest-digest@java.sun.com
% Subject: java-interest-digest V1 #252
% Reply-To: java-interest@java.sun.com
% X-Info: To unsubscribe, send 'unsubscribe' to java-interest-digest-request@java.sun.com
% Status:
% X-Info: Evaluation version at navin.westbrook.com
% Sender: owner-java-interest@java.sun.com
% Precedence: bulk
% X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
