package access for inner class

Date view Thread view Subject view Author view

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


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:14 EDT