A Conditional Permission Admin service maintains a system wide ordered table of ConditionalPermissionInfo objects. This table is called the policy table. The policy table holds an encoded form of conditions, permissions, and their allow/deny access type. A manager can enumerate, delete, and add new policies to this table via a ConditionalPermissionsUpdate object.

When a bundle is created, it creates a Bundle Protection Domain. This protection domain calculates the system permissions for that bundle by instantiating the policy table, potentially pruning any policies that can never apply to that bundle and optimizing entries that always apply.

A bundle can have local permissions defined in a Bundle Permission Resource. These are the actual detailed permissions needed by this bundle to operate. A bundle's effective permissions are the intersection of the local permissions and the system permissions. During the permission check of the Java Security Manager, each Protection Domain is first checked for the local permissions, if this fails, the complete check fails.

Otherwise, the Bundle Protection Domains of the calling bundles are consulted to see if they imply the requested permission. To imply the requested permission, the Bundle Protection Domain must find a policy in its policy table where all conditions are satisfied and where one of the policy's permissions imply the requested permission. If one of the permissions is implied, then the policy's access type decides success or failure.

Certain conditions must postpone their evaluation so that their evaluation can be minimized and grouped to prevent unwanted side effects. Postponed conditions can leverage a Dictionary object to maintain state during a single permission check.

A good working principle is to minimize permissions as much as possible, as early as possible. This principle is embodied with the local permissions of a bundle. Local permissions are defined by a Bundle Permission Resource that is contained in the bundle; this resource defines a set of permissions. These permissions must be enforced by the Framework for the given bundle. That is, a bundle can get less permissions than the local permissions but it can never get more permissions. If no such permission resource is present then the local permissions must be All Permission. The Bundle Permission Resource is defined in Bundle Permission Resource.

For example, if the local permissions do not imply ServicePermission[org.osgi.service.log.LogService,GET], then the bundle can never get the LogService object, regardless of any other security setup in the device.

The fine-grained permissions allowed by the OSGi framework are very effective with the local permissions because they can be defined by the developer instead of the deployer. The developer knows exactly what services are needed, what packages the bundle requires, and what network hosts are accessed. Tools can be used that analyze bundles and provide the appropriate local permissions to simplify the task of the developer. However, without detailed knowledge of the bundle's intrinsics, it is very difficult to create the local permissions due to their fine-grained granularity.

At first sight, it can seem odd that a bundle carries its own permissions. However, the local permissions define the maximum permissions that the bundle needs, providing more permissions to the bundle is irrelevant because the Framework must not allow the bundle to use them. The purpose of the local permissions is therefore auditing by the deployer. Analyzing a bundle's byte codes for its security requirements is cumbersome, if not impossible. Auditing a bundle's permission resource is (relatively) straightforward. For example, if the local permissions request permission to access the Internet, it is clear that the bundle has the potential to access the network. By inspecting the local permissions, the Operator can quickly see the security impact of the bundle. It can trust this audit because it must be enforced by the Framework when the bundle is executed.

An Operator that runs a fully closed system can use the local permissions to run third party applications that are not trusted to run unchecked, thereby mitigating risks. The Framework guarantees that a bundle is never granted a permission that is not implied by its local permissions. A simple audit of the application's local permissions will reveal any potential threats.

This scenario is depicted in Figure 50.2. A developer creates a bundle with local permissions, the operator verifies the local permissions, and if it matches the expectations, it is deployed to the device where the Framework verifies that the local permissions are never exceeded.

Figure 50.2 Local permissions and Deployment

Summarizing, the benefits of local permissions are:

From a business perspective it is sometimes too restrictive to maintain a fully closed system. There are many use cases where users should be able to deploy bundles from a CD, via a PC, or from an Internet web sites. In those scenarios, relying on the local permissions is not sufficient because the Framework cannot verify that the local permissions have not been tampered with.

The de facto solution to tampering is to digitally sign the bundles. The rules for OSGi signing are defined in Digitally Signed JAR Files. A digital signing algorithm detects modifications of the JAR as well as provide the means for authenticating the signer. A Framework therefore must refuse to run a bundle when a signature does not match the contents or it does not recognize the signer. Signing makes it possible to use an untrusted deployment channel and still rely on the enforcement of the local permissions.

For example, an Operator can provision its applications via the Internet. When such an application is downloaded from an untrusted site, the Framework verifies the signature. It should install the application only when the signature is trusted or when it has default permissions for untrusted bundles.

Figure 50.3 with signing

A model where the local permissions are secured with a signature works for an Operator that fully controls a device. The operator must sign all bundles before they are provisioned. In this case, the Operator acts as a gatekeeper, no authority is delegated.

This can become expensive when there are third parties involved. For example, an Enterprise could provide applications to its employees on a mobile phone that is managed by an Operator. This model is depicted in Figure 50.4. If the Enterprise always has to contact the Operator before it can provision a new version, bottlenecks quickly arise.

Figure 50.4 Delegation model

This bottleneck problem can also be solved with signing. Signing does not only provide tamper detection, it can also provide an authenticated principal. The principal can be authenticated with a certificate chain. The device contains a set of trusted certificates (depending on implementation) that are used to authenticate the certificate of the signer.

The operator can therefore safely associate a principal with a set of permissions. These permissions are called the system permissions. Bundles signed by that principal are then automatically granted those system permissions.

In this model, the Operator is still fully in control. At any moment in time, the Operator can change the system permissions associated with the principal and thereby immediately deny access to all bundles of that principal, while they are running. Alternatively, the Operator can add additional system permissions to the principal if a new service has become available to the signer's applications. For example, if the Operator installs a org.tourist.PointOfInterest service, it can grant the ServicePermission[org.tourist.PointOfInterest,GET] and PackagePermission[org.tourist,IMPORT] to all principals that are allowed to use this service. The Operator can inform the involved parties after the fact, if at all. This model therefore does not create a bottleneck.

Using digital signing to assign system permissions can therefore delegate the responsibility of provisioning to other parties. The Operator completely defines the limits of the permissions of the principal, but the signing and deployment can be done by the other parties.

For example, an Operator can define that the ACME company can provision bundles without any intervention of the Operator. The Operator has to provide ACME once with a signing certificate and the Operator must associate the ACME principal with the appropriate system permissions on the device.

The key advantage of this model is the reduced communication between ACME and the Operator: The Operator can modify the system permissions of ACME applications and be in control at any moment in time. The ACME company can develop new applications without the need to coordinate these efforts in any way with the Operator. This model is depicted in Figure 50.5, which also shows the possible sandboxes for Daffy Inc. and unsigned bundles.

Figure 50.5 Typical Delegation model

The local permissions can still play an important role in the delegation model because it provides the signer the possibility to mitigate its risk, just as it did for the Operator. Signers can verify the local permissions before they sign a bundle. Like the Operator in the earlier scenario, the signer can quickly verify the security requirements of a bundle. For example, if a game bundle requests AdminPermission[*,*], it is unlikely that the bundle will pass the security audit of the signer. However, in the unlikely case it did, it will not be granted this permission unless the Operator gave such a permission to the signer's principal on the device.

The grouping model is traditionally used because it minimizes the administration of the security setup. For example, an operator can define the following security levels:

The operator signs the bundle with an appropriate certificate before it is deployed, when the bundle is installed, it will be automatically be assigned to the appropriate security scope.

However, the behavior can also be obtained using the local permissions of a bundle.

This example provides a simple setup for a delegation model. The example is intended for readability, certain concepts will be explained later. The basic syntax for the policies is:

policy      ::= access '{' conditions permissions '}' name?
access      ::= 'ALLOW' | 'DENY'       // case insensitive 
conditions  ::= ( '[' qname quoted-string* ']' )*
permissions ::= ( '(' qname (quoted-string 
                         quoted-string?)? ')' )+
name        ::= quoted-string

For readability, package prefixes that can be guessed are replaced with "..".

The following policy has a condition that limits the permissions to bundles that are signed by ACME. The permissions given are related to managing other bundles.

ALLOW {
   [ ..BundleSignerCondition "* ; o=ACME" ]

    ( ..AdminPermission "(signer=\* ; o=ACME)" "*" )
    ( ..ServicePermission "..ManagedService" "register" )
    ( ..ServicePermission "..ManagedServiceFactory" "register" )
} "1"

The next permission policy is for bundles signed by the operator. The operator bundles get full managing capabilities as well as permissions to provide any service.

ALLOW {
    [ ..BundleSignerCondition "*; o=Operator" ]
    ( ..AdminPermission "*" "*" )
    ( ..ServicePermission "*" "get,register" )
    ( ..PackagePermission "*" "import,exportonly" )
} "2"

The following block indicates that all bundles not signed by ACME will not have access to the com.acme.secret package, nor can they provide it. In this case, only bundles that are signed by ACME may use the com.acme.secret.* packages. Instead of explicitly specifying all allowed packages for bundles not signed by ACME, it is easier to deny them the protected packages. The exclamation mark ('!' \u0021) is a parameter for the Bundle Signer Condition to reverse its normal answer. This facility is also available in the Bundle Location Condition.

That is, the following policy specifies that bundles not signed by ACME will be denied permission to package com.acme.secret.*.

DENY {
   [ ..BundleSignerCondition "* ; o=ACME" "!" ]
    ( ..PackagePermission "com.acme.secret.*" 
            "import,exportonly" )
} "3"

Basic permissions define the permissions that are available to all bundles. The basic permissions therefore have no conditions associated with them so all bundles will be able to use these permissions. All bundles may use the Log Service as well as use any package that was not yet denied earlier.

ALLOW { 
    (..ServicePermission "..LogService" "get" )
    (..PackagePermission "*" "import" )
} "4"

The resulting permissions are summarized in Table 50.1. The + indicates allow, the - means deny. The number is the deciding policy.

The system wide policy table does not contain instances, it contains encoded forms of the permissions and conditions. The policy table acts as a template for each Bundle Protection Domain; the Bundle Protection Domain creates instances with the associated bundle as their context.

It is a dynamic template because a Bundle Protection Domain must track the changes to the framework's policy table immediately and update any instances from the new encoded forms. Once the atomic commit() method of the update object has successfully returned, all subsequent use of Bundle Protection Domains must be based on the new configuration. See Permission Management for more information of how to manage this table.

The conditions and permissions of the policy table must be instantiated before the conditions can be checked. This instantiation can happen, when a Bundle Protection Domain is created, or the first time when the conditional permissions are needed because of a permission check. Figure 50.7 shows the central table and its instantiation for different Bundle Protection Domains.

Figure 50.7 Instantiation of the policy table

Condition objects must always belong to a single Bundle Protection Domain and must never be shared.

A permission check starts when the Security Manager checkPermission method is called with permission P as argument. The current Security Manager must be implemented by the Framework and is therefore called the Framework Security Manager; it must be fully integrated with the Conditional Permission Admin service.

The Framework Security Manager must get the Access Control Context in effect. It must call the AccessController getContext() method to get the default context if it is not passed a specific context.

The AccessControlContext checkPermission method must then be called, which causes the call stack to be traversed. At each stack level the Bundle Protection Domain of the calling class is evaluated for the permission P using the ProtectionDomain implies method. The complete evaluation must take place on the same thread.

Permission P must be implied by the local permissions of the Bundle Protection Domain. If this is not the case, the complete check must immediately end with a failure. Local permissions are described in Local Permissions and Bundle Permission Resource.

The permission check now depends on the instantiated policy table, called Ts. During the Bundle Protection Domain implies method, the goal is to decide if the permission P is denied, or can progress because it is potentially allowed. Potentially, because the table can contain postponed conditions that need to be executed after all protection domains are checked.

The policy table must therefore be traversed in ascending index order until the first policy is matching that can give an immediate access type. If this access type is DENY, the implies method fails and aborts the check. If an ALLOW is found, the next domain must be checked. To ensure that there is at least one immediate matching policy in the table, a virtual DENY { (AllPermission) } is added at the end of the table. This virtual policy has the effect of making the default policy DENY when no matching entries are found.

During the traversal, an optimized policy list per bundle is constructed containing the postponed conditions and at the end a matching policy. This list is evaluated after all the protection domains are checked and none of them failed.

Therefore, the following definitions begin the Bundle Protection Domain implies method's algorithm:

Ts = instantiated policy table + DENY {(AllPermission)}
PL = {}

PL will be copied from Ts until the first policy that matches. A matching policy has all of its conditions immediately satisfied and one of the permissions implies permission P. If a policy can never be matched because it has an immediate condition that cannot be satisfied, then it is not copied to PL. At the end, PL contains zero or more postponed policies followed by exactly one matching policy.

In pseudo code:

policy: 
for each policy T in Ts
    for each condition C in T conditions
        if C is immediate and C is not satisfied 
            continue policy

    found = false
    for permission X in T permissions
        found |= X implies P

    if not found
        continue policy

    add T to PL

    if T has no postponed conditions
        break

PL must now be optimized to remove superfluous policies. A postponed policy can be removed if it cannot change the outcome from the last (which is an immediate) policy. That is, if the immediate policy at the end has the same access type as the previous policy in PL, then it can be ignored. The following pseudo code removes these superfluous postponed conditions.

while PL length > 1
    if PL[PL length -2] access = PL[PL length -1] access
        remove PL[PL length -2]
    else
        break

After discarding these superfluous postponed conditions, the contents of PL has the structure outline in Figure 50.9, where Tp(x) is a postponed policy with a access type x, and Tm is a matching policy, ! is the not operator for the condition.

Figure 50.9 Structure of Postponed List PL

If PL contains only one policy and it is a DENY policy, then the Bundle Protection Domain can directly answer false from the implies method, which will abort the complete permission check evaluation. In all other cases, it must remember the postponed list PL for the given bundle, and return true.

if PL = {DENY{...}}
    return false
Bundle.pl = PL
return true

DENY {
    [ BundleSignerCondition "cn=ACME" "!" ]
    ( FilePermission "/tmp/acme/-" "READ,WRITE" )
} "0"
ALLOW { 
    ( FilePermission "/tmp/-" "READ,WRITE" )
} "1"
ALLOW {
   [ PromptCondition "Allowed to Read?" ]
   ( FilePermission "*" "READ" )
} "2"
DENY {
    [ PromptCondition "Deny Writing?" ]
     ( FilePermission "*" "READ,WRITE" )
} "3"

Tp(ALLOW)       # 2
Tp(DENY)        # 3 
Tm(DENY)        # virtual (D)

Tp(ALLOW)       # 2
Tm(DENY)        # virtual

If all protection domains have been checked and none has denied the permission by returning false, then each checked Bundle Protection Domain has a postponed list.

This per bundle postponed list contains one or more policies that must now be evaluated in sequence. The first policy in the list that can satisfy all its postponed conditions decides the access. If this policy has an access type of ALLOW, the list of the next domain is evaluated otherwise the evaluation fails.

The evaluation always ends because the last entry in each of the postponed lists is guaranteed to be a matching policy. As a special case, a postponed list with one entry indicates success. This must be a matching ALLOW because an immediate DENY would have failed earlier.

For example, if bundle A postponed policy Tp1 and bundle B postponed policy Tp2, and bundle C was immediately satisfied for ALLOW, then the constellation would like Figure 50.10.

Figure 50.10 Evaluation of postponed policies

The Conditional Permission Admin provides a type specific Dictionary object to all evaluations of the same postponed Condition implementation class during a single permission check. It is the responsibility of the Condition implementer to use this Dictionary to maintain states between invocations. The condition is evaluated with a method that takes an array and a Dictionary object: isSatisfied(Condition[],Dictionary). The array always contains a single element that is the receiver. An array is used because an earlier version of this specification could verify multiple conditions simultaneously.

The Dictionary object has the following qualities:

The algorithm for the postponed processing can now be explained with the following pseudo code:

bundle: 
for each bundle B
    policy:
    for each policy T in B.pl
        for C in T conditions
             if C is postponed and
                C is not satisfied with Dictionary
                continue policy

        if T access = DENY 
            return false
        else
            continue bundle
    assert false // can not reach
    
return true

A permission P is checked while bundle A, B, and C are on the call stack. Their security setup is as follows:

The situation for C is as follows:

ALLOW {                 (Q)     }  "C1"
ALLOW { [IC0]           (P)     }  "C2"
ALLOW { [PC2]           (P)     }  "C3"

First, the Bundle Protection Domain of bundle C is asked if it implies permission P. Bundle C has three policies. Policy C1 has no conditions, only a permission that does not imply permission P, it is therefore ignored. The second policy has an immediate condition IC0, which is not satisfied. Therefore, the policy's permissions are not even considered. The last policy contains a mutable postponed condition PC2. The permission P is implied by the related permissions. However, it is not possible to make the decision at this moment in time, therefore the evaluation of policy C3 is postponed. The postponed list for bundle C is therefore:

ALLOW {[PC2]}                      "C3"
DENY  {(AllPermission)}

This list can not be optimized because the final access type differs from the earlier access types.

The setup for bundle B is as follows:

ALLOW { [IC1][PC2][PC1] (P) (R) }  "B1"
ALLOW { [PC2]           (P) (R) }  "B2"
DENY  {                 (P)     }  "B3"
ALLOW {                 (Q)     }  "B4"

Bundle B is considered, its first policy has and immediate Condition object that is IC1. This condition turns out to be satisfied. This policy is a potential candidate because it has two postponed conditions left. It is a possibility because its permissions imply permission P. The policy is therefore placed on the postponed list.

Policy B2 is similar, it must also be placed on the postponed list because it implies permission P and it has a postponed condition PC2.

Policy B3 matches, it is therefore placed on the postponed list and the evaluation is stopped because there is an immediate decision, therefore it is not necessary to look at policy B4.

There are 2 policies postponed, the bundle is potentially permitted. Bundle's B postponed list therefore looks like:

ALLOW {[PC2][PC1]}    "B1"
ALLOW {[PC2]}         "B2"
DENY  { } 

This list cannot be optimized because the final access type differs from the earlier postponed conditions.

Last and least, bundle A.

  A:  ALLOW {  [IC1] [PC1]    (P) (Q) }    "A1"
      ALLOW {  [IC2]          (P) (R) }    "A2"
      ALLOW {                 (S)     }    "A3"

Bundle A's IC1 is evaluated first and it is satisfied. Permission P is implied by the policy A1's permissions, therefore this policy is postponed for evaluation.

Policy A2 is also satisfied and it directly implies permission P. This policy is therefore also placed on the postponed list and further evaluation is no longer necessary because it is the first matching policy. That is, policy A3 is ignored. The postponed list looks like:

ALLOW { [PC1] } "A1"
ALLOW { }       "A2"

This list is optimized to:

ALLOW {}        "A2"

After the checkPermission method of the Access Control Context method returns, the Framework Security Manager must evaluate the postponed lists of all the bundles. The list of postponed policies looks like Figure 50.10.

Figure 50.11 Evaluation of postponed policies

The Framework Security Manager must now evaluate the postponed lists for each bundle. In this example, postponed condition PC2 occurs 3 times. All these evaluations of PC2 get the same Dictionary object. If PC2 prompts the users with a specific question, then it should not ask the same question again when another PC2 is evaluated later. The Dictionary object can be used to maintain this state.

Both PC1 and PC2 prompt the user. PC1 will be rejected in this example, and PC2 will be affirmed.

First the postponed list of bundle A is evaluated. This is the trivial case of ALLOW {}, and the postponed list for bundle A succeeds with ALLOW.

For bundle B, policy T1 must prompt for PC2 and PC1. PC2 records the answer in the Dictionary that is specific for PC2. Because PC1 fails, T1 is not applicable and policy T2 must be evaluated. PC2 had recorded its answer so it does not prompt but returns true immediately. Policy T2 is an ALLOW policy and bundle B therefore ends positively.

Last, bundle C requires evaluation of policy T4. PC2 retrieves its answer from the given Dictionary object and succeeds. Policy T4 has an access type of ALLOW and this concludes the complete permission check positively.

Bundle programmers should always use the Java Security Manager to do security checks. When the Access Controller is used directly (or the Access Control Context) to do the security check instead, then the evaluation cannot handle postponed conditions. Therefore, the postponed conditions must be treated as immediate conditions by the Bundle Protection Domain when the permissions check does not go through the Framework's security manager. The implication of this is that the result of checking a permission can depend on the way the check is initiated.

For example, a bundle on the stack has the needed permission P tied to a User Prompt Condition and another bundle on the stack does not have the Permission P. The check would fail if the Security Manager was called and the user would never be prompted because the failure was detected before the conditional permissions could be evaluated. However, if the Access Control Context was called directly, the user would be prompted and fail even if the user acknowledged the request.

Conditional Permission Admin does not have a specific concept of default permissions. Default permissions are derived from the policies that do not have any Condition objects. These policies are applied to all bundles, effectively making them default permissions. This is a different from Permission Admin; in Permission Admin default permissions only apply when there are no specific permissions set.

A Bundle Signer Condition is satisfied when the related bundle is signed with a certificate that matches its argument. That is, this condition can be used to assign permissions to bundles that are signed by certain principals.

The Bundle Signer Condition must be created through its static getCondition(Bundle,ConditionInfo) method. The first string argument is a matching Distinguished Name as defined in Certificate Matching. The second argument is optional, if used, it must be an exclamation mark ('!' \u0021). The exclamation mark indicates that the result for this condition must be reversed. For example:

[ ...BundleSignerCondition "* ;cn=S&V,o=Tweety Inc., c=US"]
[ ...BundleSignerCondition "* ;cn=S&V" "!"]

The Bundle Signer Condition is immutable and can be completely evaluated during the getCondition method.

The Bundle Location Condition matches its argument against the location string of the bundle argument. Bundle location matching provides many of the advantages of signing without the overhead. However, using locations as the authenticator requires that the download locations are secured and cannot be spoofed. For example, an Operator could permit Enterprises by forcing them to download their bundles from specific locations. To make this reasonable secure, at least the HTTPS protocol should be used. The Operator can then use the location to assign permissions.

https://www.acme.com/download/*      Appsfrom ACME
https://www.operator.com/download/*  Operatorapps

The Bundle Location Condition must be created through its static getCondition(Bundle,ConditionInfo) method. The first string argument is a location string with possible wildcard asterisks ('*' \u002A). Wildcards are matched using Filter string matching. The second argument is optional, if used, it must be an exclamation mark ('!' \u0021). The exclamation mark indicates that the result for this condition must be reversed. For example:

..BundleLocationCondition "http://www.acme.com/*"
..BundleLocationCondition "*://www.acme.com/*"

The Bundle Location Condition is satisfied when its argument can be matched with the actual location.

The Bundle Location Condition is immutable and can be completely evaluated during the getCondition method.

An attacker could circumvent the local permission by simply removing the permissions.perm file from the bundle. This would remove any local permissions that were required by a signer of the bundle. To prevent this type of attack the Conditional Permission Admin must detect that the permissions.perm resource was signed, that is, present in the Manifest, but that it is not in the JAR. If the bundle is being installed when this condition is detected, the install must fail with a Bundle Exception.

There is a subtle interaction between mutability and postponement. An immutable postponed condition must be treated as a postponed conditions. This first result can then be cached. The following table shows the interaction between mutability and postponement. The Direct column indicates the steps during the permission check, the After column indicates the step when all the permissions are checked and found to allow the requested action.

This significant optimization is leveraged by the provided BundleLocationCondition and BundleSignerCondition classes. The Protection Domain will never have to consider conditional permissions that do not match the protection domain's bundle. However, a Condition object can also start as a mutable condition and later become immutable. For example, a user prompt could have the following states:

This specification provides a number of condition classes to bind permission sets to specific bundles. However, custom code can also provide conditions. See Implementing Conditions for more information about custom conditions.

Theoretically, every checkPermission method must evaluate every condition for every bundle on the call stack. That is, the Framework Security Manager must iterate through all bundles on the stack, run through the instantiated policy table of that bundle, evaluate all the conditions, test the permissions, until it finds a permission that is implied. This model would be prohibitively expensive.

Implementations are therefore urged to optimize the evaluation of the permission checks as much as possible. They are free to change the algorithms described in this specification as long as the external effect remains the same.

One optimization is pruning the instantiated policy table. A Condition object can be pruned if it is immutable.

If an immutable Condition object is satisfied, it can be removed from the policy's Condition objects because it cannot influence the evaluation anymore. If it is not satisfied, the corresponding policy can be completely discarded because one of the Condition objects is not satisfied, making it impossible for the policy to be used.

For example, assume the following policy table:

ALLOW {
    [ ...BundleLocationCondition 
          "http://www.acme.com/*" ]
    ( ...SocketPermission "www.acme.com" "connect,accept" )
} 
ALLOW {
    [ ...BundleLocationCondition 
          "http://www.et.com/*" ]
    [ ...Prompt "Phone home?" ]
    ( ...SocketPermission "www.et.com" "connect,accept" )
}

Assume this table is instantiated for a bundle with a location of http://www.acme.com/bundle.jar. The first policy's permissions can be placed in a the special Permission Collection because the Bundle Location condition is immutable and in this case satisfied.

The second policy can be discarded for this bundle because it is immutable and not satisfied for the bundle's location. Any condition that is not satisfied and immutable makes the policy ignorable.

If there is a chance that permissions will be checked in code being called by isSatisfied, the implementer of the Condition should use the AccessController doPrivileged to ensure needed permissions. For example, a User Prompt Condition has the potential to cause many permission checks as it interacts with the UI.

However, the same Condition object must not be evaluated recursively. The Framework must detect the recursive evaluation of a Condition object and act as if the second invocation returns an unsatisfied, not postponed Condition object.

For example, if a User Prompt Condition is evaluated and this evaluation accesses the UI, which in its turn checks a permission that causes the evaluation of the same User Prompt Condition, then this second evaluation must not take place and be treated as not postponed and false.

A Condition implementation is guaranteed that all evaluations necessary for a single checkPermission invocation are carried out on the same thread. However, multiple permission checks can take place on different threads. It is the responsibility of the Condition class implementers to handle these synchronization issues.

All conditions must come from the boot class path or from the Framework class loader. This is due to security reasons as well as to prevent the case that there are multiple versions of the implementation packages present. Conditions can still be downloaded with bundles by using a Framework extension bundle, see Extension Bundles.

Condition objects will get instantiated when the framework is restarted or the Bundle Protection Domain is created. Framework implementations can also use optimizations that cause Condition objects to be created and destroyed multiple times within the lifetime of an instance of a Bundle Protection Domain. An implementation of a Condition class must not make any assumptions about its creation or dereferencing.