[2597] in java-interest
typesafe socket communication
daemon@ATHENA.MIT.EDU (Zachary Simpson)
Thu Oct 5 19:44:55 1995
From: Zachary Simpson <zsimpson@eden.com>
To: "'java-interest@java.sun.com'" <java-interest@java.sun.com>
Date: Sat, 7 Jan 1995 15:46:57 -0600
In a previous message, Arthur said that remote persistent objects were =
not implementable because of a hornet's nest of security problems. We =
think that we understand these security problems, but we're not sure. =
We're guessing that you mean that arbitray type casts from byte[] to =
some class will mean that it is possible to "lie" to the runtime system =
and convince it that you're handing it one structure when in fact you're =
handing it something else. However, this is only a security problem if =
any of the destination fields of the class are considered pointers (i.e. =
not atomic data types like int, etc.) Even if the data stream did get =
typecast into a class which contained an object pointer, these object =
pointers could be double checked against the heap address space during =
the instanciation to avoid creating a pointer outside of the heap (i.e. =
a potential virus).
Thus, we clearly don't understand the problem since Arthur is saying =
that there is a big security risk here. As far as we can tell, you =
should be able to implement this is a totally typesafe fashion. =
Additionally, it seems like the ClassLoader class already has this =
problem (other than the fact that we can't figure out how to write out a =
class that it knows how to read back in! :)
We are experimenting with realtime multiuser games with clients in Java =
and the servers in C++. We want to transmit a structured message to the =
client and then create a class instance from the data stream. To make =
this fast, we want to identify class type with an integer handle as =
opposed to having some sort of magic class identification using the name =
of the class or some other methodology.
Now, non-atomic data members clearly pose a major problem. If there is =
some data element like an array or another object inside of this class, =
then the typecast is much more compilcated. Here are two potential ways =
to deal with this that would solve our problems:
1. Disallow runtime casts (i.e. generate an exception) for casts to =
classes which contain non-atomic members. Disadvantage: no arrays! :(
2. Create a standardized way of linearizing/delinearizing arrays. For =
example:
class MyMessage {
int a;
arraylength byte len;
byte[len] b;
}
With this information, the runtime system could typecast though some =
native thing like a ClassLoader from a byte[] to a MyMessage and it =
would delinearize into a traditional java structure. That is, the =
byte[] would be non-linear in the heap relative to the instance =
MyMessage (i.e. there's a pointer in MyMessage to b). Furthermore, it =
would be an exception to write to the arraylength field.
This is kind of a kludge, but it would make efficient commincation a lot =
simpler than having to write out the java equivilent of this for every =
single class type. For example, the following sucks:
class 3DPoint {
int x, y, z;
static 3DPoint loadMe(DataInputStream s) {
3DPoint p =3D new 3DPoint();
p.x =3D s.readInt();
p.y =3D s.readInt();
p.z =3D s.readInt();
return p;
}
}
class MyMessage {
int a;
byte len;
3DPoint[] b;
static MyMessage loadMe(DataInputStream s) {
MyMessage myMessage =3D new MyMessage();
myMessage.a =3D s.readInt()
myMessage.len =3D s.readByte();
myMessage.b =3D new 3DPoint [len];
for (int i=3D0; i<len; i++) {
myMessage.b[i] =3D 3DPoint.loadMe (s);
}
return myMessage;
}
}
This code will work just fine under Java now, its just really really =
annoying to have to keep this in sync with the class strucutres if =
you've got a lot of them and they change a lot and you're trying to do =
it in C++ simultaneously for the server. Feel our pain! :) Grief!!!
Please help!
Thanks
Zachary Simpson
Jim Greer
Titanic Entertainment
zsimpson@eden.com
jgreer@eden.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
