An implementation of the OSGi Permission Admin
Copyright 2004 TRIALOG
This bundle is meant to handle the SECURITY of YOUR FRAMEWORK.
If I were you, I wouldn't use it without a minute review of its source. And this shouldn't be that difficult since it is a really small bundle, completely separated from the framework implementation.
This implementation by Trialog of the OSGi Permission Admin service is licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
The Permission Admin implementation relies on kXML and XML Pull, which have their own licenses, available at the root of the bundle sources.
Given the implementation of the
java.security.Policy.setPolicy
method,
the Permission
s granted to the
PermissionAdminPolicy
are determined by
the previous security Policy
(most
likely sun's default policy).
So, in order for the Permission Admin to work, you need to define permissions “outside of itself”, even if there is absolutely no permission defined within OSGi (which results in AllPermission for all bundles).
grant codeBase "file:../bundle/permissionadmin.jar" {
permission org.osgi.framework.AdminPermission;
permission org.osgi.framework.ServicePermission "org.osgi.service.permissionadmin.PermissionAdmin", "register";
permission java.security.SecurityPermission "setPolicy";
};
On the other hand, all the permissions set before starting the PA will be lost. As an improvement, it shall be possible to import the previous permissions if no save file is found.
embedded
folder contains the Java library(ies) to be embedded in the bundle.lib
folder contains other Java
library(ies) that are needed by the compiler but that will not be
embedded in the bundle.src
folder contains the Java
classes of the Permission Admin implementation. Details of the
classes is available in the Architecture section.Example.policy
contains a sample Java
policy to be used to start the Permission Admin within the Oscar
OSGi framework.license-*
contains the licenses of the
included software.manifest.mf
is the manifest file to be
included in the bundle.
You will find here a brief introduction to the architecture of this implementation of the Permission Admin service. For further details please refer to the Javadoc or directly to the source.
PermissionAdminActivator
This is the OSGi activator of the bundle. It creates an instance of the PermissionAdmin implementation and registers it in the service registry. When stopped, it triggers saving the permissions.
PermissionAdminImpl
It implements the PermissionAdmin
interface, as defined by OSGi.
As of J2SE 1.4, the java.security.Policy class caches the permissions used by the implies method. So there is no need to implement another cache in this bundle.
PermissionInfo
can be considered immutable since all the fields used by this class
are private and the getters are final. So simply using the clone()
method on the PermissionInfo array should suffice to ensure that no
side-effect could occur.
PermissionAdminPolicy
It defines a security policy based on
the PermissionInfo
s owned by the
Permission Admin.
Logger
It is a utility class in charge of printing logs to the console.
XmlHandler
it is used to parse the permissions saved as an XML file and to save the permissions into a file.
There is one point of the OSGi standard that this implementation is not complying with and will never be: The Permission Admin is provided as a bundle while the standard states it shall be integrated into the framework.
The previous Policy instance could be saved and given to this implementation.
Check the behavior of this bundle when it is updated.
Find a way to "modify"
the java.security.Policy
cache. This
cache must be invalidated when permissions are changed or if new
Permission classes are made available to the framework.
Handle UnresolvedPermission
:
The policy shall listen to bundle events to update its
PermissionCollection
-s when a new,
missing Permission
is installed. And
the other way round, when a bundle is removed.
Previous Policy
should be used to get additional Permission
s
and return all
Using the LogService
(when available) would be nice. Unfortunately, since the
PermissionAdmin
is most likely started
before everything else, nothing is available, not even the
LogService
interface. It is also likely
that the ServiceTracker
class should
also be emulated.