Karl Pauls wrote:
I am currently using Felix with a security manager and I have noticed some
permission errors (access denied during the opening of local files with "all
permissions").
Could you please be a bit more specific about the actual
setup/configuration/error? Does the framework really have all
permission?
I am using an embedded Felix framework.
The launcher is starded with the option -Djava.security.policy that
points to my java.policy config file.
Before starting the framework, I set the security manager if no exists.
I define all permission in the java.policy config file as below:
grant {
// Allow everything for now
permission java.security.AllPermission;
};
Here my stack trace:
2008-07-01 14:41:25,992 : StandardWrapperValve.invoke : Servlet.service() for
servlet default threw exception
java.security.AccessControlException: access denied (java.io.FilePermission
D:\JOnAS\base\work\webapps\jonas\ear\j2ee-1.4_2008.06.23-16.40.22.ear\earsample.war\index.html
read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.lastModified(File.java:793)
at
org.apache.naming.resources.FileDirContext$FileResourceAttributes.getLastModified(FileDirContext.java:1065)
at
org.apache.naming.resources.ProxyDirContext.revalidate(ProxyDirContext.java:1491)
at
org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.java:1452)
at
org.apache.naming.resources.ProxyDirContext.lookupCache(ProxyDirContext.java:1377)
at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:643)
at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:325)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
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:585)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
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:276)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at
org.ow2.jonas.web.tomcat6.ResetAuthenticationValve.invoke(ResetAuthenticationValve.java:95)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.ow2.jonas.web.tomcat6.versioning.CoyoteAdapterWithDelegatedContextSearch.service(CoyoteAdapterWithDelegatedContextSearch.java:300)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
In this case, the ProtectionDomain doesn't contain neither the
sourcecode, nor a permission collection to decide if we can access to
the requested resource.
I hope that the issue is more clear.
This issue has appeared since the commit 618095. In fact, the
BundleProtectionDomain calls the super class ProtectionDomain without
specifying the source code or the permissions. Before this commit, both of
them were set (for the permission, it was at nay rate not acceptable).
Well, we do have some support for security implemented as an extension
bundle. It is not complete yet but a start. As a consequence, we don't
support the normal Java policy file way of assigning permissions
anymore. What should happen in case the framework has all permissions,
a security manager is set but the extension bundle is not installed is
that all bundles loaded by the framework should have all permissions
as well.
I think that the BundleProtectionDomain should call the ProtectionDomain
constructor by setting the source code attibute in order to load the
security policies relative to a bundle url.
It might be possible to default to the permissions in the current
policy in case we don't have security support. I'll look into it.
However, it is not as easy as specifying the source only because we
take over permission checks for bundles -- hence, the source attribute
would be ignored.
regards,
Karl
What do you thing?
Regards,
François
