> 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.
But maybe it's own policy?
> 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.
Interesting ... It would be great to find out why this is the case!
> 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)
Is tomcat inside a bundle? I guess I'm getting a little confused
again. Can you please explain your set-up a bit more?
> Anyway, I will try a different approach and check if my problems comes from
> jonas.
I can add the location of the bundle again if need be but I'd still
like to figure out what is going on first. Again, the idea is the
felix should take over all security related things hence, the
protection domain is only needed as a wrapper. There shouldn't be
anybody else messing with it with the exception of the security check
calling implies().
> I'll keep you informed. Thank you for your help.
That would be great. I need to get around to work on the security
again (pretty busy right now) but I definitely would like to clear
this one up. I'll start to experiment a bit myself tonight too.
regards,
Karl
> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Karl Pauls
[EMAIL PROTECTED]
