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

Weld proxies fail access control checks when a SecurityManager is present

    Details

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  swd847 Stuart Douglas
                  Reporter:
                  dmlloyd David Lloyd
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: