Hello alltogether,
maybe this isn't the right place to ask this question, but because my examples
also result in a segmentation violation using your new port of the JDK-1.2
(thanks a lot for the good work!) you may take this just as a hint for
a bug concerning the binary compatibility (see CH13 of java language
specification).
Assume the following two classes:
public class PublicMethod {
public void fkt() {
System.out.println("public fkt() was called!");
}
}
public class CallPublic {
public static void main(String argv[]) {
PublicMethod pm=new PublicMethod();
// use the public method 'fkt()'
pm.fkt();
}
}
Executing 'CallPublic' results in a message "public fkt() was called!" as
expected. After that, I change the access modifier of method fkt() in class
PublicMethod from public to private:
public class PublicMethod {
private void fkt() {
System.out.println("private fkt() was called!");
}
}
I recompile class PublicMethod and leave CallPublic untouched. Then, when
CallPublic is executed, I get "private fkt() was called!" in spite of the
private access modifier (in JDK-1.1.7 - JDK-1.2 signals a segmentation
violation)! This behaviour also occurs when changing access
modifiers of member variables. As mentioned in the language specification,
this could be rated as a feature and not a bug (binary compatibility).
But it is left to the implementor of the JVM, how the JVM reacts in such
a case ("Changing the declared access of a member or constructor to permit
less access _may_ break compatibility with pre-existing binaries, causing a
linkage error to be thrown when these binaries are resolved.").
Now, when I want to create an environment, where I can dynamically load
further classes to execute them in this environment, how can I prevent,
that someone builds bytecode, that accesses the private members and methods
of this runtime environment (similar applets, that get access to the
AppletContext).
Well, when using an interface (like AppletContext), you get an
"IncompatibleClassChangeError: Unimplemented interface method" if you
change the access modifier of the implemented method to private. But
if a possible attacker writes ByteCode that performs a type cast on the
reference that he has got as a interface type from the runtime environment,
he can call its private methods and members if he knows their names and
the class name of the implementation (maybe by using the reflection api).
Is there someone who can give me a hint, how to solve this problem?
Thanks in advance!
Dirk
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
