[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] OSGi for Server-side...

> On Tuesday 25 October 2005 14:28, Kaegi, Simon wrote:
> > 1) Running when someone else has set the URL and URLConnection singletons
> > needed by the URLHandlerService - patched but needs polishing
> Big problem without co-operation from the "conflictee". However, more
> importantly, how about when loading many Equinox instances in the same JVM,
> and resolving the URLHandler issue across those... Richard hall is sketching
> 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 important
> > consideration in some server-side environments - without control of the
> > 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 if an
> 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 a
> better job than the "default" one, then mission accompilshed. (provided the
> 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.

> Cheers
> Niclas