glassfish
  1. glassfish
  2. GLASSFISH-4608

Unexpected Principal in SecurityContext

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 9.1peur1
    • Fix Version/s: 9.1.1
    • Component/s: security
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      4,608
    • Status Whiteboard:
      Hide

      911ToScrub

      Show
      911ToScrub

      Description

      I have an application that uses Quartz for job scheduling started via servlet
      QuartzInitializerServlet which is automatically started during server startup or
      deployment and init(ServletConfig cfg) is called.

      The problem is, when undeploying and deploying application from netbeans (which
      is done under "admin" user using
      org.apache.tools.ant.taskdefs.optional.sun.appserv.DeployTask via ant), the
      init() method of servlet is executed under Principal "admin", and not under
      "ANONYMOUS" as it is done when server is restarted. This creates problems
      because then jobs run under different Principals depending on how was
      application initialized (via server startup or redeployment).

      When you call SecurityContext.getCurrent().getCallerPrincipal(); in init()
      method of a servlet with <load-on-startup>1</load-on-startup> in web.xml, the
      bug manifests itself.

      I believe SecurityContext should be switched to default unathorized context when
      initializing web application modules even when redeploying applications.

      This problem was detected in Glassfish V2ur1. I haven't tested V2ur2.

        Activity

        Hide
        harpreet added a comment -

        Please scrub issue and see if it is critical to v2.1.

        Show
        harpreet added a comment - Please scrub issue and see if it is critical to v2.1.
        Hide
        kumarjayanti added a comment -

        the problem can be workedaround by configuring an unprivileged @RunAs for the
        QuartzInitializerServlet.

        The Java EE spec may not allow one to specificy an anonymous role as the run-as
        role, but they could certainly configure the initializer to run with an
        unprivileged role.

        Show
        kumarjayanti added a comment - the problem can be workedaround by configuring an unprivileged @RunAs for the QuartzInitializerServlet. The Java EE spec may not allow one to specificy an anonymous role as the run-as role, but they could certainly configure the initializer to run with an unprivileged role.

          People

          • Assignee:
            raharsha
            Reporter:
            jarol1
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: