As all worked fine with the version 1.0.3 of Felix and no more with the
version 1.0.4, I have done my investigations on Felix. The differences I
have seen between the two versions could explain my errors. I'm sure
that jonas or tomcat doesn't set its own security manager. I think we
cannot see felix in the stack because the stack corresponds to a http
request and the tomcat module has already been initialized previously. I
have tested to set the codesource of the BundleProtectionDomain to the
url of the bundle (as in the version 1.0.3) and it works again.
Furthermore, I am a little confused to see that the
BundleProtectionDomain does not define neither the codesource, the
permissions, the classloader, or the principals. So, when we check
permission for a specific resource requested by the tomcat bundle, the
protection domain associated to the current security context is empty
(the same protection domain previously initialized by Felix)
Anyway, I will try a different approach and check if my problems comes
from jonas.
I'll keep you informed. Thank you for your help.
Regards,
François
Karl Pauls wrote:
Well, I can not see a single felix class on the stack ... are you sure
that it is related to felix? Furthermore, if the policy you showed
would be in effect, why would there ever be any security exception in
the first place? Is it maybe possible that the outside (looks like
tomcat and jonas) sets it's own security manager or policy?
regards,
Karl
On Tue, Jul 1, 2008 at 3:02 PM, François Fornaciari
<[EMAIL PROTECTED]> wrote:
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
