Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-1751

Weld proxies fail access control checks when a SecurityManager is present

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 2.2.6.Final, 3.0.0.Alpha1
    • None
    • None
    • None

      When a Weld proxy is generated, its class initializer is seeded with bytecode which uses Class#getDeclaredMethod() calls to get information about proxied methods. Unfortunately the target class of these calls may include classes which belong to a different class loader (such as Object.class). This causes the fast security check in SecurityManager to fail and fall back to checking for RuntimePermission("accessDeclaredMembers"), which fails because the proxy is in a protection domain which generally does not contain this permission.

      Some possible ideas for a fix:

      1. Generate a synthetic protection domain for weld proxies which duplicates the target protection domain but also includes this permission (beware creating large numbers of them though; some kind of mapping cache is in order)
      2. Disable access checking while initializing classes via the special WildFlySecurityManager.doUnchecked mechanism (this would require a new dependency on wildfly-security-manager though, and only works when that library is the active security manager)
      3. Modify the proxy generation scheme so that only the current class is the target of getDeclaredMethods(), somehow.

              sdouglas1@redhat.com Stuart Douglas (Inactive)
              dlloyd@redhat.com David Lloyd
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: