Securing your applications - OSGi in Action - page 447

■ lifecycle —Install, update, and uninstall
■ listener —Add/remove a synchronous bundle listener
■ metadata —Retrieve bundle headers and location
■ resolve —Resolve and refresh
■ resource —Get resources
■ startlevel —Set the start level, and initial the start level
■ context —Get the bundle context
The special action * represents all actions. As you can see, AdminPermission gives you
fine-grained control over which bundles can do what on which bundles. For example,
assume a bundle wants to install another bundle using code like this:

context.installBundle("file:bundle.jar").start();
This triggers the framework to check whether all code on the call stack has the
following:
■ AdminPermission.LIFECYCLE permission for the installed bundle
■ AdminPermission.EXECUTE permission for the installed bundle
This is relatively straightforward, although granting the permission can be a little con-
fusing. The thing to remember about AdminPermission is that you use it to grant a
bundle the right to perform specific operations on other bundles. The filter con-
structor parameter is how you specify the bundles that can be controlled. For a more
complicated example, you can grant an AdminPermission like this:

new AdminPermission("(&(signer=CN=core,O=baz,C=de)(name=org.foo.*)
(location=file://*)(id>=10))", AdminPermission.LIFECYCLE + "," +
AdminPermission.EXECUTE);
The bundle granted this permission can perform the operations associated with
AdminPermission.LIFECYCLE and AdminPermission.EXECUTE on bundles with a
signer matching CN=core,O=baz,C=de (more on signing later), a symbolic name start-
ing with org.foo , a location starting with file:// , and a bundle identifier greater
than 10. Granted, this is completely contrived, but it illustrates the possibilities.
You've now seen the module- and lifecycle-layer permissions, which means you
have one framework layer to go—services.

14.3.4 ServicePermission

ServicePermission is a service-layer permission for controlling which services a bun-
dle can provide or use. As with the other permissions, the actual permission granted is
controlled by its constructor parameters, as shown in table 14.5.
You can use * or a trailing .* as a wildcard to target several service interfaces or
classes with a single permission. The get action grants the ability to use the specified
services, whereas the register action grants the ability to provide the specified ser-
vices. For the get action, you can also use an LDAP filter for name , which matches