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]
