[hibernate-issues] [Hibernate-JIRA] Updated: (HV-171) JSR-303 must specify how to run in environments that use a SecurityManager
Ed Burns (JIRA)
noreply at atlassian.com
Fri Jun 19 14:38:33 EDT 2009
[ http://opensource.atlassian.com/projects/hibernate/browse/HV-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ed Burns updated HV-171:
------------------------
Attachment: message.txt
the domain.xml given to Ed Burns by Ron Monzillo that turns on better logging of security related exceptions.
Running the SimpleBVServlet on GlassfishV3 with SecurityManager enabled, and with this domain.xml in place, will show what kinds of grant statements need to be added to the server.policy file to enable JSR-303 to work without security exceptions being thrown.
The process of discovering what kind of grant statements will likely be iterative, with each iteration looking like
1. run the BV servlet test
2. study the log to see what kinds of grant statements are needed
3. add the grants to the server.policy
Once the grant statements are decided, then we need to craft some common code that all callers who wish to use JSR-303 within a SecurityManager enabled container must place around their calls to whatever JSR-303 calls need the security. This will likely be couched in a AccessController.doPrivledged() call.
> JSR-303 must specify how to run in environments that use a SecurityManager
> --------------------------------------------------------------------------
>
> Key: HV-171
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-171
> Project: Hibernate Validator
> Issue Type: Improvement
> Components: documentation
> Affects Versions: 4.0.0.Beta1
> Environment: Glassfish V3 with Security Manager Enabled
> Reporter: Ed Burns
> Attachments: message.txt
>
>
> When running the JSR-303 Impl that is Hibernate Validator 4.0.0.Beta1 on a container with a SecurityManager, such as Glassfishv3 with the SecurityManager enabled, calling simple validator code such as:
> Set<ConstraintViolation<Person>> violations =
> beanValidator.validate(person);
> Will cause an AccessControlException, as shown in the following stack trace:
> [#|2009-06-19T11:22:20.347-0400|SEVERE|glassfish|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=17;_ThreadName=Thread-1;|StandardWrapperValve[SimpleBVServlet]: PWC1406: Servlet.service() for servlet SimpleBVServlet threw exception
> java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
> at org.hibernate.validation.util.ReflectionHelper.setAccessibility(ReflectionHelper.java:195)
> at org.hibernate.validation.engine.BeanMetaDataImpl.initFieldConstraints(BeanMetaDataImpl.java:233)
> at org.hibernate.validation.engine.BeanMetaDataImpl.initClass(BeanMetaDataImpl.java:207)
> at org.hibernate.validation.engine.BeanMetaDataImpl.createMetaData(BeanMetaDataImpl.java:179)
> at org.hibernate.validation.engine.BeanMetaDataImpl.<init>(BeanMetaDataImpl.java:106)
> at org.hibernate.validation.engine.BeanMetaDataImpl.<init>(BeanMetaDataImpl.java:96)
> at org.hibernate.validation.engine.ValidatorImpl.getBeanMetaData(ValidatorImpl.java:559)
> at org.hibernate.validation.engine.ValidatorImpl.validateConstraints(ValidatorImpl.java:225)
> at org.hibernate.validation.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:189)
> at org.hibernate.validation.engine.ValidatorImpl.validate(ValidatorImpl.java:110)
> at simple_bv_servlet.SimpleBVServlet.doGet(SimpleBVServlet.java:76)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 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:319)
> 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:352)
> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:209)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1499)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:293)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:187)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
> at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:353)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:249)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:147)
> at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:746)
> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:655)
> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:905)
> at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:161)
> at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
> at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
> at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
> at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
> at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:637)
> Some remedies include:
> 1. Explicitly accounting for SecurityManager considerations in the JSR-303 Java API
> 2. Mentioning in the spec prose what a caller that wishes to use SecurityManager must do to enable JSR-303 to work without throwing security related exceptions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list