You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by François Fornaciari <fr...@bull.net> on 2008/07/01 13:37:14 UTC
BundleProtectionDomain does not define permissions
Hi all,
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").
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).
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.
What do you thing?
Regards,
François
Re: BundleProtectionDomain does not define permissions
Posted by Karl Pauls <ka...@gmail.com>.
> 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
>> <fr...@bull.net> 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
karlpauls@gmail.com
Re: BundleProtectionDomain does not define permissions
Posted by François Fornaciari <fr...@bull.net>.
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
> <fr...@bull.net> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: BundleProtectionDomain does not define permissions
Posted by Karl Pauls <ka...@gmail.com>.
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
<fr...@bull.net> 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
karlpauls@gmail.com
Re: BundleProtectionDomain does not define permissions
Posted by François Fornaciari <fr...@bull.net>.
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
>>
>>
>
>
>
>
Re: BundleProtectionDomain does not define permissions
Posted by Karl Pauls <ka...@gmail.com>.
> 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?
> 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
karlpauls@gmail.com