From: Godmar Back (gback@cs.utah.edu)
Date: Sun Dec 13 1998 - 15:05:50 EST
>From http://www.javasoft.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc7.html#17241
Security implications
If an inner class C requires access to a private member m of an enclosing
class T, the inserted access method for m opens up T to illegal access by
any class K in the same package. There at present are no known security
problems with such access methods, since it is difficult to misuse a method
with package scope. The compiler can be instructed to emit warnings when
it creates access methods, to monitor the creation of possible loopholes.
If a class N is a protected member of another class C, then N's class file
defines it as a public class. A class file attribute correctly records
the protection mode bits. This attribute is ignored by the current virtual
machine, which therefore will allow access to N by any class, and not just
to subclasses of C. The compiler, of course, will correctly diagnose such
errors, because it looks at the attribute. This is not a security hole,
since malicious users can easily create subclasses of C and so gain access
to N, protected or not.
Likewise, if a class is a private member of another class, its class
file defines it as having package scope, and an attribute declares the
true access protection, so that 1.1 compilers can prevent inadvertant
access, even within the package.
In other words, if the class is a separate class in the same package,
as ThreadFinalizer is, the compiler will not prevent access to it.
If it is an anonymous private inner class, as in Alexandre's original
idea, at least the compiler will prevent these attempts.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:14 EDT