Re: Need a new access modifier?
Patricia Shanahan wrote:
John Ersatznom wrote:
Patricia Shanahan wrote:
I think the key issue here is whether access to classes from inside the
same package has security implications or not. The current treatment is
good enough to prevent accidental misuse by a non-malicious programmer.
Unfortunately, we all know what happens when a security mechanism is
designed around the threat model of "accidental misuse by a
non-malicious programmer", don't we? :)
Of course. The question I'm asking is whether the distinction between
private and package access should be considered part of the security
model at all.
Do you think it should, and if so, why?
Either it should, or package access should be easier to lock down.
Anyone can put a class in your package simply by including "package
yourpackagename;" at the start of the code, after all. The key to
locking out such classes would probably be at the level of jar files.
You'd have to have some way for one such file to be the "canonical" one
for a given package, and then prevent class-loading anything into that
package that isn't from that jar. Making that jar tamper-evident with an
MD5 sum or similar (e.g. making it a signed jar) would then complete the
picture. The trick is dealing with the case that there's multiple jars
for a package. Which one is the "right" one? Specifying it (by MD5 or
similar hash) for every security-sensitive package in another
tamper-evident file for which there's no ambiguity is one option. That
file would be per-application rather than per-jar. Another is to use
whichever jar has a class named the same as the package in question, and
consider any case of having different jars (different hash) with classes
with the same (fully qualified) name, named after the containing
package, to be an error (and any case of nonidentical classes sharing a
fully-qualified name an error, but I expect that's already the case).