Securing your applications - OSGi in Action - page 448

Table 14.5 ServicePermission constructor parameters

Parameter Description

String name

Service interface or class name(s)

String actions Comma-delimited list of the actions granted by the permission ( get or register )

against the associated service properties in addition to the same set of bundle proper-
ties described for BundlePermission ( signer , location , id , and name ).
To get a better understanding of how this permission is used, consider the follow-
ing snippet of code a bundle can use to find a service and to register a service:

context.getServiceReference("org.foo.Service");
context.registerService("org.bar.Service", new Service(), null);
Here you find an org.foo.Service service and register an org.bar.Service service.
This triggers the framework to check whether all code on the call stack has the following:
■ ServicePermission.GET for the org.foo.Service interface
■ ServicePermission.REGISTER for the org.bar.Service interface
These permission checks are straightforward. For the associated bundle to perform
these tasks, you can grant it these permissions:

new ServicePermission("org.foo.*", ServicePermission.GET);
new ServicePermission("org.bar.Service", ServicePermission.REGISTER);
In the first permission, you use a wildcard to allow it to access all services in the
org.foo package. In the second permission, you specifically allow it to register
org.bar.Service services.
That completes the OSG i-specific permissions you can grant to bundles. Before we
move on to discussing permission management, let's briefly discuss file permissions,
because they behave slightly differently in an OSG i environment.

14.3.5 Relative file permissions

Although java.io.FilePermission isn't defined by the OSG i specification, it's still
impacted by how the framework interprets it. In a standard Java environment, a file
permission created with a relative path is interpreted as being relative to the directory
from which the Java process was started (the current working directory). This isn't the
case in an OSG i environment. Instead, it's treated as relative to the root of the private
data area of the associated bundle.
Typically, this doesn't have much of an effect, especially because the framework
automatically grants bundles permission to read, write, and delete files in their own
private area. The main thing this enables is the ability to grant a bundle additional
permissions for files in its private data area, such as the execute permission.
Enough of describing permissions. Next, we'll discuss how you manage them with
the Conditional Permission Admin Service.