[GLASSFISH-8455] Need to detect wrong user is at the controls Created: 27/May/09  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Byron Nevins Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 8,455
Tags: 3_1-exclude


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.


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.
(Permission denied))
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
(Permission denied))
ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
(Permission denied))

Comment by Byron Nevins [ 27/May/09 ]

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
Comment by Richard S. Hall [ 27/May/09 ]

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.

Comment by km [ 27/May/09 ]

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 ...

Comment by Byron Nevins [ 27/May/09 ]

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
at java.util.logging.FileHandler.openFiles(FileHandler.java:372)
at java.util.logging.FileHandler.<init>(FileHandler.java:270)
at com.sun.enterprise.admin.launcher.GFLauncher.setup(GFLauncher.java:150)
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)

Comment by Byron Nevins [ 27/May/09 ]

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.

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

                          • BEFORE **************
                            ERROR: org.apache.felix.framework.cache.BundleCache: Error creating archive.
                            (Permission denied))


java.io.IOException: Couldn't get lock for

                          • 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...

Comment by Byron Nevins [ 27/May/09 ]

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

Comment by km [ 27/May/09 ]

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.

Comment by km [ 27/May/09 ]

Now the right Sahoo ...

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

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.

Comment by km [ 18/Sep/09 ]

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.

Comment by Tom Mueller [ 14/Feb/11 ]

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.

Comment by Tom Mueller [ 28/Feb/11 ]

Marking this as an RFE.

Comment by Tom Mueller [ 05/Apr/11 ]

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.

Generated at Mon Mar 02 12:17:50 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.