AccessibleObject.setAccessible() backward compatibility

Remi Forax forax at univ-mlv.fr
Fri Sep 11 17:31:19 UTC 2015


Thinking a little more about the check in setAccessible,
i think it is useless because it can be easily bypassed.

setAccessible() is implemented by changing a field override,
so to avoid the security check, one can change the field directly.

  private static final Field OVERRIDE;
  static {
    try {
      OVERRIDE = AccessibleObject.class.getDeclaredField("override");
    } catch (NoSuchFieldException | SecurityException e) {
      throw new AssertionError(e);
    }
    OVERRIDE.setAccessible(true);  // works because AccessibleObject is in java.base
  }
  
  private static void setAccessible(AccessibleObject object) throws AssertionError {
    try {
      OVERRIDE.setBoolean(object, true);
    } catch (IllegalAccessException e) {
      throw new AssertionError(e);
    }
  }

I really like the fact that you can use setAccessible() to bypass the check of setAccessible()

Rémi

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Vendredi 11 Septembre 2015 19:15:35
> Objet: AccessibleObject.setAccessible() backward compatibility
> 
> There are two changes to setAccessible that make migration to the module
> universe hard.
> 
> The first one is that setAccessible() is now declared final which is a binary
> incompatible change so it breaks Guava two projects of mine.
> 
> The second change is that now setAccessible() is now CallerSensitive and
> throw an exception if the AccessibleObject is not visible from the caller
> class.
> While this change may improve the security, it's a backward incompatible
> change is not strictly required to support modules it's more an enhancement
> of the current security model and i don't think it's a good idea to mix it
> with the introduction of the module support. More philosophically, every
> libraries that propose an abstraction that hide underlying dirts provides an
> escape hatch, the reflection API is one of such hatch of Java the language
> allowing to bypass the typechecker and the security sandbox. Trying to close
> the hatch will just make people to open holes in the nearby wall with hacks
> that are less secure and that may even compromise the integrity of the
> plateform.
> 
> cheers,
> Rémi
> 


More information about the jpms-spec-experts mailing list