Here's a dumbass question

Discussion in 'Java' started by James D Carroll, Jun 19, 2004.

  1. 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,


    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004
    James D Carroll, Jun 19, 2004
    #1
    1. Advertising

  2. James D Carroll

    Roedy Green Guest

    On Fri, 18 Jun 2004 20:33:53 -0400, "James D Carroll"
    <> wrote or quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 19, 2004
    #2
    1. Advertising

  3. James D Carroll

    Jim Cochrane Guest

    In article <>, James D Carroll wrote:
    > 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.

    --
    Jim Cochrane;
    [When responding by email, include the term non-spam in the subject line to
    get through my spam filter.]
    Jim Cochrane, Jun 19, 2004
    #3
  4. James D Carroll

    Roedy Green Guest

    On Sat, 19 Jun 2004 00:46:39 GMT, Roedy Green
    <> wrote or quoted :

    >try it and see what happens.
    >
    >Also try it with one of your own packages.


    You will discover the classes of most interest are final!

    See http://mindprod.com/products.html#LEDATASTREAM
    what convolutions I went through to extend DataInputStream and
    DataOutputStream to handle little-endian data.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 19, 2004
    #4
  5. James D Carroll

    Liz Guest

    "James D Carroll" <> wrote in message
    news:...
    > 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.
    Liz, Jun 19, 2004
    #5
  6. James D Carroll

    Chris Smith Guest

    James D Carroll wrote:
    > 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
    Chris Smith, Jun 19, 2004
    #6
  7. James D Carroll

    Tony Morris Guest

    > >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
    Tony Morris, Jun 20, 2004
    #7
  8. Liz wrote:

    > "James D Carroll" <> wrote in message
    > news:...
    >
    >>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.


    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
    John C. Bollinger, Jun 21, 2004
    #8
  9. James D Carroll

    Roedy Green Guest

    On Sat, 19 Jun 2004 10:39:52 -0600, Chris Smith <>
    wrote or quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 21, 2004
    #9
  10. James D Carroll

    Chris Smith Guest

    Roedy Green wrote:
    > 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
    Chris Smith, Jun 21, 2004
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Child
    Replies:
    3
    Views:
    324
    John Timney \(Microsoft MVP\)
    Aug 8, 2003
  2. Replies:
    8
    Views:
    377
    Peter Shaggy Haywood
    Sep 10, 2006
  3. Ryan Davis
    Replies:
    0
    Views:
    129
    Ryan Davis
    Oct 23, 2008
  4. FAQ server
    Replies:
    0
    Views:
    154
    FAQ server
    Aug 10, 2006
  5. FAQ server
    Replies:
    0
    Views:
    128
    FAQ server
    Oct 7, 2006
Loading...

Share This Page