Here's a dumbass question

J

James D Carroll

I don't know why I never thought of this, but we know that there is the
"package" level of protection for methods. Let's say that there is a package
that I'm interested in. Could I create a class that of the same package to
gain access to them? Could I create a class as

package java.lang

public class MyClass{...}


and get access to all the methods all the methods that were supposed to be
for the original class in that package only?


Thanks,
 
R

Roedy Green

package java.lang

public class MyClass{...}


and get access to all the methods all the methods that were supposed to be
for the original class in that package only?

try it and see what happens.

Also try it with one of your own packages.
 
J

Jim Cochrane

I don't know why I never thought of this, but we know that there is the
"package" level of protection for methods. Let's say that there is a package
that I'm interested in. Could I create a class that of the same package to
gain access to them? Could I create a class as

package java.lang

public class MyClass{...}


and get access to all the methods all the methods that were supposed to be
for the original class in that package only?

It's not really a dombass question, but it is a dumbass subject line.
A sujbect line that gives a brief summary of what your question is about
will tend to get much more helpful responses than otherwise.
 
L

Liz

James D Carroll said:
I don't know why I never thought of this, but we know that there is the
"package" level of protection for methods. Let's say that there is a package
that I'm interested in. Could I create a class that of the same package to
gain access to them? Could I create a class as

package java.lang

public class MyClass{...}


and get access to all the methods all the methods that were supposed to be
for the original class in that package only?


Thanks,
I think so, just put the class file in the same directory. But you
may find that users will be reluctant to put your class there on their
systems.
 
C

Chris Smith

James said:
I don't know why I never thought of this, but we know that there is the
"package" level of protection for methods. Let's say that there is a package
that I'm interested in. Could I create a class that of the same package to
gain access to them?

It depends. JAR files provide a feature called package sealing, which
prevents that from happening. If a package is sealed, then an attempt
to define a new class in that package will fail. Since the 'java.lang'
package is sealed by the boot classloader, you won't be able to define a
new class in that package.

You can seal your own packages as well, with appropriate manifest
attributes.

(In case you go out looking for ways around this, note that you could
define a class in a package named java.lang if you did so in a
classloader that's not related to the boot classloader, but that would
not be sufficient to get access to package-level members of the standard
java.lang package.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
T

Tony Morris

package java.lang
try it and see what happens.

Violation of the terms of use.
What "might happen" is legal action from Sun.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform
 
J

John C. Bollinger

Liz said:
I think so, just put the class file in the same directory. But you
may find that users will be reluctant to put your class there on their
systems.

In principle you can do this. You do not need to have the source or
even any class files for a package in order to assign your own classes
to it. If you do have source or class files, they do not need to be in
the same directory. You do not necessarily need to package all the
classes for any particular package into the same jar. You will find,
however, that there is a mechanism for signing jar files, and a
mechanism for "sealing" them (which instructs the JVM to not permit any
other sources to provide classes in specified packages). So the
language permits you to added classes willy-nilly to any package you
choose, but you may not be able to get those classes loaded for use.

All the practicalities aside, my advice to you is "don't do that." If
you're dealing with a well-designed API then you should assume that
there is good reason for the package-private methods to be assigned that
access level, and if you don't deeply understand the implementations of
the various classes in the package then you just shouldn't be messing
with the package-protected methods. On the other hand, if you're
dealing with a poorly-designed API then you may have problems even using
it in the "expected" manner, and worming in to access package-protected
methods is just asking for (more) trouble. The answer is the same
either way.


John Bollinger
(e-mail address removed)
 
R

Roedy Green

It depends. JAR files provide a feature called package sealing, which
prevents that from happening.

It would seem this would be fairly easy to defeat. Just unzip the jar
and repackage it without the seal.

To defend itself, the code would have to check it is signed with a
particular key. But that code could be changed to look for a
different key or no key.


I think sealing is designed to prevent accidental or casual hacking,
not a serious attack.
 
C

Chris Smith

Roedy said:
It would seem this would be fairly easy to defeat. Just unzip the jar
and repackage it without the seal.

To defend itself, the code would have to check it is signed with a
particular key. But that code could be changed to look for a
different key or no key.

I think sealing is designed to prevent accidental or casual hacking,
not a serious attack.

Yes and no. On the one hand, it's obviously insufficient to protect
against modifying the functionality of code on a system where the
attacker has full control. Nothing is ever sufficient for that case
(hence the adage that client-side security is doomed).

On the other hand, package sealing is an essential part of a security
setup in which untrusted mobile code is run under a security manager,
but the attacker doesn't otherwise have control over the host system.
In that case, it's not possible to rejar the system classes, which are
the critical piece here because they have access to protected resources.
It's perfectly safe to use package access for methods that might have
security concerns, assuming you sign the package.

Yes, package signing also prevents accidental violation of
encapsulation, but it is appropriate for some security issues as well.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top