glassfish
  1. glassfish
  2. GLASSFISH-8455

Need to detect wrong user is at the controls

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      This is a Felix Issue – but there is no Subcomponent for core or startup or
      OSGi so I just set it to Admin for now.

      ==================================
      Scenario:

      Normal GF installation.
      logged in as non-root user
      start the domain
      stop the domain
      login as root
      start the domain
      stop the domain
      login as normal user again.

      That's all folks – you can never start the server again. Only root can.

      No messages appear in server.log.

      But ALL the messages appear in the window when starting this way:
      asadmin start-domain --verbose

      There are hundreds of the following errors (I just have a few here because they
      are all very similar)

      Auto-properties install: org.osgi.framework.BundleException: Unable to cache
      bundle: file:/export/home/bnlocal/glassfishv3/glassfish/modules/osgi-main.jar
      Auto-properties start: org.osgi.framework.BundleException: Unable to cache
      bundle: file:/export/home/bnlocal/glassfishv3/glassfish/modules/osgi-main.jar
      ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
      (java.io.FileNotFoundException:
      /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle140/version0.0/revision.location
      (Permission denied))
      ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
      (java.io.FileNotFoundException:
      /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle141/version0.0/revision.location
      (Permission denied))
      ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
      (java.io.FileNotFoundException:
      /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle142/version0.0/revision.location
      (Permission denied))

        Activity

        Hide
        Byron Nevins added a comment -

        I did not set this Issue to P1 only because there is an easy work-around:

                • WORK-AROUND *****
                  1) login as root
                  2) rm -rf install-dir/domains/domain1/felix-cache
                  3) Now you can start the domain from non-root account
        Show
        Byron Nevins added a comment - I did not set this Issue to P1 only because there is an easy work-around: WORK-AROUND ***** 1) login as root 2) rm -rf install-dir/domains/domain1/felix-cache 3) Now you can start the domain from non-root account
        Hide
        Richard S. Hall added a comment -

        Isn't this normal? Felix can only write to where it has permission to write. If
        you create a cache with root ownership, then it makes sense that you cannot use
        a non-root user to access it.

        Show
        Richard S. Hall added a comment - Isn't this normal? Felix can only write to where it has permission to write. If you create a cache with root ownership, then it makes sense that you cannot use a non-root user to access it.
        Hide
        km added a comment -

        I agree with Richard. You should only get to run the domains that you own. In
        this case, since the root has a permission to do anything on local file system,
        it is actually able start your domain in first place. If you manage the
        permissions properly, the root a/c on this machine probably will not even be
        able to start domain owned by you.

        AFAIK, felix cache not being readable by another user is one of the defenses we
        have for the server startup to fail if started by that user. To be better,
        Byron, you should try to do the same experiment with two normal non-super-user
        accounts, say "joe" and "blo". Neither of them should be able to start the
        domain who is owned (on the file system) by the other. This is also the reason
        why the doman's config folder has 0600 permissions. Alas, it does not work with
        super-user ...

        Show
        km added a comment - I agree with Richard. You should only get to run the domains that you own. In this case, since the root has a permission to do anything on local file system, it is actually able start your domain in first place. If you manage the permissions properly, the root a/c on this machine probably will not even be able to start domain owned by you. AFAIK, felix cache not being readable by another user is one of the defenses we have for the server startup to fail if started by that user. To be better, Byron, you should try to do the same experiment with two normal non-super-user accounts, say "joe" and "blo". Neither of them should be able to start the domain who is owned (on the file system) by the other. This is also the reason why the doman's config folder has 0600 permissions. Alas, it does not work with super-user ...
        Hide
        Byron Nevins added a comment -

        Below is what you get when you try to start a domain with Joe trying to start
        Blow's domain:

        -bash-3.00$ asadmin start-domain
        java.io.IOException: Couldn't get lock for
        /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log
        at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
        at java.util.logging.FileHandler.<init>(FileHandler.java:270)
        at
        com.sun.enterprise.admin.launcher.GFLauncherLogger.addLogFileHandler(GFLauncherLogger.java:98)
        at com.sun.enterprise.admin.launcher.GFLauncher.setup(GFLauncher.java:150)
        at
        com.sun.enterprise.admin.cli.StartDomainCommand.runCommandNotEmbedded(StartDomainCommand.java:82)
        at
        com.sun.enterprise.admin.cli.StartDomainCommand.runCommand(StartDomainCommand.java:47)
        at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:171)
        at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:105)
        at com.sun.enterprise.admin.cli.AsadminMain.local(AsadminMain.java:126)
        at com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:77)

        Show
        Byron Nevins added a comment - Below is what you get when you try to start a domain with Joe trying to start Blow's domain: -bash-3.00$ asadmin start-domain java.io.IOException: Couldn't get lock for /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log at java.util.logging.FileHandler.openFiles(FileHandler.java:372) at java.util.logging.FileHandler.<init>(FileHandler.java:270) at com.sun.enterprise.admin.launcher.GFLauncherLogger.addLogFileHandler(GFLauncherLogger.java:98) at com.sun.enterprise.admin.launcher.GFLauncher.setup(GFLauncher.java:150) at com.sun.enterprise.admin.cli.StartDomainCommand.runCommandNotEmbedded(StartDomainCommand.java:82) at com.sun.enterprise.admin.cli.StartDomainCommand.runCommand(StartDomainCommand.java:47) at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:171) at com.sun.enterprise.cli.framework.CLIMain.invokeCommand(CLIMain.java:105) at com.sun.enterprise.admin.cli.AsadminMain.local(AsadminMain.java:126) at com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:77)
        Hide
        Byron Nevins added a comment -

        Lowering priority.

        I think it is important for GF to be more self-aware. These messages
        indirectly say what the problem is but you have to figure them out. GF will
        look smarter if it does this interpretation itself. Also not starting a domain
        is catastrophic and worth a few cycles developing extra code.

        Recommended Fix:
        In ASMAin do the checks and spit out an appropriate message if the permissions
        are not correct.

        checks:
        a) File.canWrite() on the felix cache dir if it exists
        b) File.canWrite() on domain.xml

                                • BEFORE **************
                                  (1)
                                  ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
                                  (java.io.FileNotFoundException:
                                  /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle141/version0.0/revision.location
                                  (Permission denied))

        or

        (2)
        java.io.IOException: Couldn't get lock for
        /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log

                                • AFTER **********************

        You do not own this domain and/or have the correct OS privileges. You are not
        allowed to start this domain. Blah blah blah...

        Show
        Byron Nevins added a comment - Lowering priority. I think it is important for GF to be more self-aware. These messages indirectly say what the problem is but you have to figure them out. GF will look smarter if it does this interpretation itself. Also not starting a domain is catastrophic and worth a few cycles developing extra code. Recommended Fix: In ASMAin do the checks and spit out an appropriate message if the permissions are not correct. checks: a) File.canWrite() on the felix cache dir if it exists b) File.canWrite() on domain.xml BEFORE ************** (1) ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive. (java.io.FileNotFoundException: /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/felix-cache/gf/bundle141/version0.0/revision.location (Permission denied)) or (2) java.io.IOException: Couldn't get lock for /export/home/bnlocal/glassfishv3/glassfish/domains/domain1/logs/server.log AFTER ********************** You do not own this domain and/or have the correct OS privileges. You are not allowed to start this domain. Blah blah blah...
        Hide
        Byron Nevins added a comment -

        One more thing.

        If you get into this situation – you will not see any error messages at all
        from asadmin – unless you run with --verbose. Here is what start-domain says:

        Domain (domain1) did not respond in 90 seconds. It means it is still coming up
        or it has failed to come up. Check server.log for details.

        Of course there is nothing in server.log because you did not have permission to
        write to it!

        But you can read it and see nothing:

        rw-rr- 1 bnlocal other 0 May 27 10:10 server.log

        Show
        Byron Nevins added a comment - One more thing. If you get into this situation – you will not see any error messages at all from asadmin – unless you run with --verbose. Here is what start-domain says: Domain (domain1) did not respond in 90 seconds. It means it is still coming up or it has failed to come up. Check server.log for details. Of course there is nothing in server.log because you did not have permission to write to it! But you can read it and see nothing: rw-r r - 1 bnlocal other 0 May 27 10:10 server.log
        Hide
        km added a comment -

        I personally think we should rather check for the permissions on domain.xml than
        depending on Felix Cache or Log File. But since it's Felix that starts way too
        early in the startup, it may be appropriate to do these checks there.

        Sahoo – do you mind taking a look into ASMain and fixing it like Byron suggests?
        If you think it should instead be fixed elsewhere, let me know or assign it to me.

        Show
        km added a comment - I personally think we should rather check for the permissions on domain.xml than depending on Felix Cache or Log File. But since it's Felix that starts way too early in the startup, it may be appropriate to do these checks there. Sahoo – do you mind taking a look into ASMain and fixing it like Byron suggests? If you think it should instead be fixed elsewhere, let me know or assign it to me.
        Hide
        km added a comment -

        Now the right Sahoo ...

        Show
        km added a comment - Now the right Sahoo ...
        Hide
        Sanjeeb Sahoo added a comment -

        There are other code which gets executed during server startup before Felix is
        started. So, I suggest we do this security check early in the startup process.
        Any way, I don't have time to do this now. So, feel free to fix or attach a patch.

        Show
        Sanjeeb Sahoo added a comment - There are other code which gets executed during server startup before Felix is started. So, I suggest we do this security check early in the startup process. Any way, I don't have time to do this now. So, feel free to fix or attach a patch.
        Hide
        km added a comment -

        Sahoo, I understand that you don't have time to look into this now, but
        assigning this to me is something of a surprise. I thought you owned ASMain.

        Show
        km added a comment - Sahoo, I understand that you don't have time to look into this now, but assigning this to me is something of a surprise. I thought you owned ASMain.
        Hide
        Tom Mueller added a comment -

        This issue still exists in GlassFish 3.1 and the trunk. However, to see the behavior, it is necessary to remove the domain1/osgi-cache directory before starting the domain as root so that the entire osgi-cache is created by root.

        Bumping up the priority based on the age of the issue and targeting for 3.2.

        Show
        Tom Mueller added a comment - This issue still exists in GlassFish 3.1 and the trunk. However, to see the behavior, it is necessary to remove the domain1/osgi-cache directory before starting the domain as root so that the entire osgi-cache is created by root. Bumping up the priority based on the age of the issue and targeting for 3.2.
        Hide
        Tom Mueller added a comment -

        Marking this as an RFE.

        Show
        Tom Mueller added a comment - Marking this as an RFE.
        Hide
        Tom Mueller added a comment -

        A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

        Show
        Tom Mueller added a comment - A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

          People

          • Assignee:
            kumara
            Reporter:
            Byron Nevins
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: