Hi Casper,
I guess the standard solution for restricting the imports of certain bundles
would be to enable OSGi-Security. In this case a bundle needs a special
permission to import packages from another bundle, and you can use the
ConditionalPermissionAdmin service to configure the permissions. For instance,
if you deploy the system bundles to the ./system folder and custom extensions
to ./custom, then you could use the following permissions to a) run your system
bundles without any restrictions (they have all permissions) b) restrict your
customers' bundles to import the "my.api" package:
allow { [org.osgi.service.condpermadmin.BundleLocationCondition
"file:./system/*"] (java.security.AllPermission)} "system-bundles"
allow { [org.osgi.service.condpermadmin.BundleLocationCondition
"file:./custom/*"] (org.osgi.framework.PackagePermission "my.api" "import")}
"api-import"
Alternatively, you could explicitly deny only certain imports to the custom
bundles:
deny { [org.osgi.service.condpermadmin.BundleLocationCondition
"file:./custom/*"] (java.security.AllPermission)
(org.osgi.framework.PackagePermission "my.internal.api" "import")
(org.osgi.framework.PackagePermission "something.else" "import")}
"critical-imports"
allow { [org.osgi.service.condpermadmin.BundleLocationCondition
"file:./custom/*"] (java.security.AllPermission)} "all-the-rest"
Instead of bundle location, you can also use signer information to grant/deny
permissions.
Unfortunately, there are few useful resources on the topic of OSGi security
available, but the spec might be helpful:
https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html
https://osgi.org/specification/osgi.core/7.0.0/framework.security.html
To run OSGi with security enabled you need to add a file "all.policy" with
content "grant { permission java.security.AllPermission; };" and specify the
properties "-Dorg.osgi.framework.security=osgi
-Djava.security.policy=<PATH/TO/all.policy>".
With Felix you also need to add the bundle
org.apache.felix/org.apache.felix.framework.security to your run configuration
(a framework extension bundle), the latest version is 2.6.1 (works at least for
Felix framework >= 5.6.10).
Best,
Christoph
>>> Casper van der Tuin <casper.vandert...@planonsoftware.com> 05.11.2018 09:17
>>> >>>
Hi Felix users,
Our solution consists of a set of bundles running in an Felix container
(Host). We want to open up our part of API for other teams to extends the
solution with additional bundles. As these should not be able to import all
the exports from the other bundles and platform, the idea was to have have a
bundle startup another felix container (Extension) and only export the
packages of our open API for bundles running within this container. However
when protoyping this we ran into the issue that the bundles running within
the Extension container will use the class loader from the Host container
instead of the class loader from the Extension container. Which could make
sense as the Felix classes are contained on the Host.
We also tried to include the felix jars inside the Extension bundle (to have
the complete felix in the Extension bundle class loader). Unfortunately this
blokced starting up the bundle, as the Activater instantiated in to startup
the Extension bundle is now not created in the same classloader as the where
it is used in the Host container, resulting in a class cast exception.
Does any one have an idea on how to solve this issue, i.e. so that bundles
runnning in the Extension container will load classes from the class loader
of the Extension container bundle? Or have any other solution to restrict
the imports of some of the bundles running in the Felix container?
Greetings,
Casper
--
Sent from:
http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
