Issue Details (XML | Word | Printable)

Key: GLASSFISH-18581
Type: Bug Bug
Status: Resolved Resolved
Resolution: Invalid
Priority: Minor Minor
Assignee: JeffTancill
Reporter: phendley
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

inconsistent Access Control Check related to grant for: java.util.logging.LoggingPermission "control"

Created: 30/Mar/12 04:02 PM   Updated: 22/Mar/13 12:17 AM   Resolved: 22/Mar/13 12:17 AM
Component/s: security
Affects Version/s: 4.0_b29
Fix Version/s: None

Time Tracking:
Not Specified


mac (snowleopard) using promoted build of and still seeing the issue in most recent nightly of

Participants: JeffTancill and phendley

 Description  « Hide

I am able to see this with a CTS test but have not had success creating a standalone test independent of CTS.

The issue is that I see an Access Control Failure the first time I run a particular cts test (it causes the test to fail). But I do not get this Access Control Failure on subsequent runs of the same test. Only after recycling glassfish, will I see this Access Control failure again. And once I get the failure, (again) subsequent runs all pass and I do not see the failure again until the next glassfish restart.

If I add the correct permission/grant to server.policy than I will not see the access control failure. The grant in question is:
permission java.util.logging.LoggingPermission "control"

It's not clear if I should always need to add this grant or not - but there is inconsistency with the checking of this grant. So, If I add the above grant to the server.policy file, then I don't get this failure. Only when this grant is missing, will I see the failure the FIRST time I run the test after a fresh glassfish restart.

Also, I'm not sure if the containers are relevant but my test was attempting to access code I had in a utility library that was contained in glassfish3/glassfish/lib directory. (again this works everytime EXCEPT not the first time after a glassfish restart - assuming I dont have the proper grant in my server.policy file.)

I am not able to include CTS source in this bug - please contact me and I will work with you to help reproduce the issue in your environment.

The stack trace I see in the server.log when I get this failure is:

[#|2012-03-29T16:30:17.471-0400|FINE|44.0||_ThreadID=18;_ThreadName=Thread-3;;MethodName=doImplies;|JACC Policy Provider, failed Permission Check at :
at java.lang.SecurityManager.checkPermission(
at java.util.logging.LogManager.checkAccess(
at java.util.logging.Handler.checkAccess(
at java.util.logging.Handler.setLevel(
at com.sun.ts.tests.jaspic.tssv.util.TSFileHandler.configure(
at com.sun.ts.tests.jaspic.tssv.util.TSFileHandler.<init>(
at com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactoryForStandalone.initializeTSLogger(
at com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactoryForStandalone.<init>(
at com.sun.ts.tests.jaspic.spi.common.CommonTests._ACF_getFactory(
at com.sun.ts.tests.jaspic.spi.baseline.Client.ACF_getFactory(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.runTest(
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.doGet(
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at Method)
at org.apache.catalina.core.StandardWrapper.service(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardPipeline.doInvoke(
at org.apache.catalina.core.StandardPipeline.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.doService(
at org.apache.catalina.connector.CoyoteAdapter.service(
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(
at org.glassfish.grizzly.ProcessorExecutor.execute(
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(
at org.glassfish.grizzly.threadpool.AbstractThreadPool$


phendley added a comment - 02/Apr/12 04:13 PM

update - 3/2/2012
Spoke with developer and this is not a glassfish bug. The failure we see happens during static init of our ACF - thats why we only see it during GF restart. The resolution is for us to add proper permission to server.policy as part of our config.
recommend - closing this out as Not a Bug.