[equinox-dev] Re: Missing doPriv when creating a new URL with a custom h

["Karl Pauls" <karlpauls@xxxxxxxxx>]

And another one this time regarding file permission:

java.security.AccessControlException: access denied
(java.io.FilePermission
/Users/pauls/equinox/configuration/org.eclipse.osgi/bundles/1/1/bundlefile
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.isFile(File.java:745)
        at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest(EclipseStorageHook.java:381)
        at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.createCachedManifest(EclipseStorageHook.java:367)
        at org.eclipse.core.runtime.internal.adaptor.CachedManifest.getManifest(CachedManifest.java:38)
        at org.eclipse.core.runtime.internal.adaptor.CachedManifest.get(CachedManifest.java:133)
        at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getResourceBundle(ManifestLocalization.java:99)
        at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getHeaders(ManifestLocalization.java:53)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:1020)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:968)

am I missing something (I use the PermissionAdmin to give permissions
to my bundles and set the default permissions to null). This kind of
internal access should be handled by the framework right?

regards,

Karl


On Wed, Mar 12, 2008 at 11:36 AM, Karl Pauls <karlpauls@xxxxxxxxx> wrote:
> Hi,
>
>  it looks to me like there is a missing doPriv around creating a new
>  URL with a custom handler:
>
>  java.security.AccessControlException: access denied
>  (java.net.NetPermission specifyStreamHandler)
>         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.net.URL.checkSpecifyHandler(URL.java:629)
>         at java.net.URL.<init>(URL.java:354)
>         at org.eclipse.osgi.baseadaptor.BaseData.getEntry(BaseData.java:104)
>         at org.eclipse.osgi.internal.baseadaptor.AdaptorUtil.loadManifestFrom(AdaptorUtil.java:192)
>         at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest(EclipseStorageHook.java:371)
>         at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.createCachedManifest(EclipseStorageHook.java:367)
>         at org.eclipse.core.runtime.internal.adaptor.CachedManifest.getManifest(CachedManifest.java:38)
>         at org.eclipse.core.runtime.internal.adaptor.CachedManifest.get(CachedManifest.java:133)
>         at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getResourceBundle(ManifestLocalization.java:99)
>         at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getHeaders(ManifestLocalization.java:53)
>         at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:1020)
>         at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:968)
>
>  the bundle in question has been installed using the config.ini
>  osgi.bundles property hence, looks like:
>
>  initial@file:/Users/pauls/...
>
>  Is this a known issue? For now I can work around it by giving my
>  calling bundle the needed permission but I do think this is something
>  the framework should do by creating the urls for its internal
>  protocols in a doPriv, no?
>
>  regards,
>
>  Karl
>
>  --
>  Karl Pauls
>  karlpauls@xxxxxxxxx
>



-- 
Karl Pauls
karlpauls@xxxxxxxxx