The equinox launcher is what I had in mind. I've opened a bug <https://bugs.eclipse.org/bugs/show_bug.cgi?id=366123> to track that enhancement.
Thanks for your help, Borislav On Thu, Dec 8, 2011 at 9:47 PM, Thomas Watson <[email protected]> wrote: > Which launcher are you interested in particular? > > There is the standard OSGi launching API (org.osgi.framework.launch) which > Equinox implements with the org.eclipse.osgi.launch.EquinoxFactory class. > This API is meant to be used by a launcher implementation as a standard way > of constructing and initializing an OSGi Framework instance. In my view it > would not be correct to add anything to the standard OSGi launching API > implementation for auto configuring permissions. This should be left in > the hands of the code that invokes the standard OSGi launching API. So if > you are using the standard OSGi launching API to launch Equinox I think you > should place your logic for setting permissions in your own code which is > constructing the Framework instance. > > There is also the equinox launcher (implemented with the > org.eclipse.equinox.launcher jar). This jar is used by the native > eclipse.exe launcher to startup the typical eclipse installation (IDE, RCP > etc.). This jar ends up using the eclipse specific launching class > org.eclipse.core.runtime.adaptor.EclipseStarter. We could consider adding > an option to this launch path to setup the initial permissions. If this is > what you are interested in then please open a bug. > > Tom > > > > > |------------> > | From: | > |------------> > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |"Kapukaranov, Borislav" <[email protected]> > | > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Equinox development mailing list <[email protected]>, > > | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |12/08/2011 11:28 AM > | > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> > > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Re: [equinox-dev] OSGi security manager in Equinox > | > > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > Thanks for the clarification. I was really hoping this could be achieved > with a standard launcher. > Do you feel it would be beneficial to users if the equinox.launcher could > optionally configure the [Conditional]PermissionAdmin with specified > permissions? > I'm willing to contribute :) > > Best Regards > Borislav > > -----Original Message----- > From: [email protected] [ > mailto:[email protected]] On Behalf Of Thomas Watson > Sent: Thursday, December 08, 2011 7:01 PM > To: Equinox development mailing list > Subject: Re: [equinox-dev] OSGi security manager in Equinox > > You should never edit the .permdata file directly. That file is an > implementation detail for the framework that is used to persistently store > the cond perm admin table as managed by the [Conditional]PermissionAdmin > services. > > The launcher should configure the cond perm admin table the same way as a > normal bundle, by using the [Conditional]PermissionAdmin service. The way > your custom launcher figures out what to populate the > [Conditional]PermissionAdmin service with is an implementation detail of > your launcher. You could use your own file or some other mechanism to > drive the code in your launcher to call the methods on the > [Conditional]PermissionAdmin service. > > Tom > > > > > > From: "Kapukaranov, Borislav" <[email protected]> > > > To: Equinox development mailing list <[email protected]>, > > > Date: 12/08/2011 10:37 AM > > > Subject: Re: [equinox-dev] OSGi security manager in Equinox > > > > > > > > I agree, this is the best place and a regular bundle after that will do. > The trick is to initialize the table in the first place. > I couldn't find a documented way to do that. One pointer I think might be > relevant, judging on the code, is the .permdata file that is read when a > new BasePermissionStorage is created. I'm not really sure where this file > should be placed, but I assume in "/configuration/org.eclipse.osgi"? > > Do you know of that's the right way to initialize the conditional > permission table? Also what should be the syntax of that file? > If there's another way I'm all ears :) > Also I got the impression this initialization can be achieved with the > standard launcher, right? > > Thanks, > Borislav > > -----Original Message----- > From: [email protected] [ > mailto:[email protected]] On Behalf Of Thomas Watson > Sent: Thursday, December 08, 2011 4:26 PM > To: Equinox development mailing list > Subject: Re: [equinox-dev] OSGi security manager in Equinox > > Hi Borislav, > > Your intuition is correct. The best place for setting the initial > conditional permission table is in the launcher after initializing the > framework (Framework.init()) with an empty storage area. But after that I > think using a normal bundle (configurator type bundle) to do the ongoing > management of the permission table is fine. > > Tom > > > > > > From: Borislav Kapukaranov <[email protected]> > > > To: Equinox development mailing list <[email protected]>, > > > Date: 12/07/2011 09:59 PM > > > Subject: Re: [equinox-dev] OSGi security manager in Equinox > > > > > > > > Thanks Tom, that was really helpful. > > > At this point I wonder if the only way to configure a secure framework is > to make sure you start a bundle right after the framework has booted which > will configure the (C)PA? > Any other ways to achieve that in addition to having a custom launcher? I'm > looking for a best practice here :-) > Why custom launcher - I suppose that's safer because it won't be affected > by any provisioning mechanism that can reorder your bundles' start or > rewrite your config.ini. > > > Thanks, > Borislav > > > On Dec 7, 2011 8:56 PM, "Thomas Watson" <[email protected]> wrote: > The policy file (specified by java.security.policy) is only used by class > loaders that extend SecureClassloader. So things like the > URLClassLoader, > the application and extension class loader etc. A bundle's class loader > does not pay attention to the java.security.policy file. > > The protection domains used by the OSGi bundle class loaders are only > configured by the ConditionalPermissionAdmin and the deprecated > PermissionAdmin services. By default if no permissions are set through > the > [Conditional]PermissionAdmin services then the bundles get AllPermission > by > default. Section 50.11 of the Core OSGi specification gives more details > on this. > > Tom > > > > > > From: Borislav Kapukaranov <[email protected]> > > To: Equinox development mailing list <[email protected]>, > > Date: 12/07/2011 11:18 AM > > Subject: [equinox-dev] OSGi security manager in Equinox > > > > > > > Hi folks, > > I'm playing with OSGi's security manager in Equinox and the > implementation > of the Conditional Permissions Admin called SecurityAdmin. > My setup is Equinox + some other bundles. This is launched by the > equinox.launcher and I've passed the following as system properties: > -Declipse.security=osgi > -Djava.security.policy="my.policy > The policy looks like that > keystore "myKeystore"; > grant signedBy "myself" { > permission java.security.AllPermission; > }; > I have signed all bundles in /plugins with that keystore and granted them > all premissions with the policy. > > The first thing I noticed is that without a policy file the framework > still > starts. That is because when we are in OSGi security mode the launcher > adds > all permissions to itself and the framework. > I created a simple bundle that in its Activator creates a directory at a > location different from it's data file. It doesn't have any local > permissions. > The call went into the EquinoxSecurityManager then started checking for > implied permissions at the AccessControlContext. The important point is > checking the Protection Domains. It went through two of them: > 1. The system bundle's protection domain as the system bundle triggered > the > Activator of my bundle. > 2. The bundle's protection domain, probably for local permissions. > 1) has all permission as it is the framework and 2) doesn't have any > local > permission therefore by specification gets AllPermission. > So far so good. > > My question is how the EquinoxSecurityManager is expected to be > configured? > From what I've seen the policy file syntax doesn't support the permission > syntax defined in the OSGi specification(ALLOW, DENY). > Does that mean OSGi's security manager is configured only by a bundle > interacting with the Conditional Permission Admin service? > Also does the policy file play any role at all in such setup? I suspect > it's relevant only for pure Java security setup. > > Thanks, > Borislav_______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
