> On Tuesday 25 October 2005 14:28, Kaegi, Simon
> > 1) Running when someone else has set the URL and URLConnection
> > needed by the URLHandlerService - patched but needs polishing
> Big problem without co-operation from the "conflictee".
> importantly, how about when loading many Equinox instances in the
> and resolving the URLHandler issue across those... Richard hall is
> on this problem, and I think collaboration is a good thing here.
Yes collaboration is good here. I have spent
time discussing this problem and possible solutions with Richard Hall. The
current solution Richard is implementing in Felix is likely the best we can
do for this situation. Unfortunately the solutions is pretty complex and
I would definitely only want to enable it if more than one framework is running
in the VM.
There is still a problem with Richard's solution,
because it still assumes the Framework can set the singleton URLStreamHandlerFactory
for the VM. In Simon's case we want the core framework to still function when setting the URLStreamHandlerFactory fails and
therefore the URLHandlerService is unavailable.
> > 2) Using the Conditional Permission
Admin Service when someone else has set
> > the SecurityManager. - avoided this so far but it's an
> > consideration in some server-side environments - without control
> > SecurityManager we lose the capability to do postponed decisions
(?) - What
> > are the repercussions? Is there something we can do about it?
> Two things comes to mind;
> 1. User can specify the SecurityManager from commandline, and
> application doesn't do the selective setting of the SM, then that
is a bug.
> If you can convince the deployment team that the SM from Equinox does
> better job than the "default" one, then mission accompilshed.
> technical difficulties to have the SM separated out bla bla bla...)
Here are the technical difficulties: - The SecurityManager specified at commandline must
be available on the application classloader or its parent classloaders
(i.e. ext, boot). When Equinox is launched the code for the framework
is loaded with a separate classloader (not the app classloader) so it's security
manager cannot be specified at commandline. - Moving the FrameworkSecurityManager out of the core
framework. This has issues because it uses some core OSGi interfaces (e.g. org.osgi.service.condpermadmin.Condition). These
classes would also have to be separated from the framework. This
is not good situation IMO.
> 2. If the deployer decides to stick with the default security,
> shouldn't this
> "just work" for Equinox as well?? Not sure, what to put
in the security
> policy codebase URLs, but shouldn't be impossible.
OSGi actually assumes complete control here. Each
bundle in OSGi has a single ProtectionDomain. This ProtectionDomain is controlled
by the Framework and dictates what permissions a class loaded from
a bundle will have. When the Framework defines a class it specifies the correct
bundle ProtectionDomain depending on what bundle the class bytes came form.
The bundle ProtectionDomain uses a policy to assign permissions
based on input from the PermissionAdmin and ConditionalPermissionAdmin services
defined by the OSGi specification. No other policy is used to assign
permissions to a bundle's ProtectionDomain. Regardless of what SecurityManager
is used the ProtectionDomain for the Class being check is what
defines the permissions a particular class gets granted.
The only reason a "special" FrameworkSecurityManager
is needed is to process postponed conditions correctly. In Equinox we
detect this situation and treat all postponed conditions as non-postponed conditions
if the SecurityManager is not our own "special"
implementation. What we have to decide is if we care about postponed conditions in
the scenarios we are trying to run in.