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
Operations

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

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

Environment:

mac (snowleopard) using promoted build of glassfish-4.0-b29.zip and still seeing the issue in most recent nightly of glassfish-4.0-b31-03_30_2012.zip.


Tags:
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|javax.enterprise.system.core.security|_ThreadID=18;_ThreadName=Thread-3;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper;MethodName=doImplies;|JACC Policy Provider, failed Permission Check at :
java.lang.Exception
at com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:408)
at com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:244)
at java.security.ProtectionDomain.implies(ProtectionDomain.java:224)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:352)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.util.logging.LogManager.checkAccess(LogManager.java:930)
at java.util.logging.Handler.checkAccess(Handler.java:284)
at java.util.logging.Handler.setLevel(Handler.java:239)
at com.sun.ts.tests.jaspic.tssv.util.TSFileHandler.configure(TSFileHandler.java:91)
at com.sun.ts.tests.jaspic.tssv.util.TSFileHandler.<init>(TSFileHandler.java:120)
at com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactoryForStandalone.initializeTSLogger(TSAuthConfigFactoryForStandalone.java:604)
at com.sun.ts.tests.jaspic.tssv.config.TSAuthConfigFactoryForStandalone.<init>(TSAuthConfigFactoryForStandalone.java:57)
at com.sun.ts.tests.jaspic.spi.common.CommonTests._ACF_getFactory(CommonTests.java:81)
at com.sun.ts.tests.jaspic.spi.baseline.Client.ACF_getFactory(Client.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ts.lib.harness.EETest.run(EETest.java:495)
at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.runTest(JaspicServletVehicle.java:110)
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.doGet(JaspicServletVehicle.java:78)
at com.sun.ts.tests.common.vehicle.jaspicservlet.JaspicServletVehicle.doPost(JaspicServletVehicle.java:100)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:323)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:321)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:356)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:212)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1583)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:163)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:164)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:816)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:567)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:547)
at java.lang.Thread.run(Thread.java:680)

#]


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.