Module org.postgresql.pljava.internal
Package org.postgresql.pljava.policy

Class TrialPolicy

  • public class TrialPolicy
extends Policy
    An implementation of Policy intended for temporary use while identifying needed permission grants for existing code.

    This policy is meant to operate as a fallback in conjunction with the normal PL/Java policy specified with the pljava.policy_urls configuration setting. This policy is activated by specifying an additional policy file URL with -Dorg.postgresql.pljava.policy.trial=url in the pljava.vmoptions setting.

    Permission checks that are allowed by the normal policy in pljava.policy_urls are allowed with no further checking. Permissions denied by that policy are checked in this one. If denied in this policy, that is the end of the matter. A permission check that is denied by the normal policy but allowed by this one is allowed, with a message to the server log.

    The log message begins with POLICY DENIES/TRIAL POLICY ALLOWS: and the requested permission, followed by an abbreviated stack trace. To minimize log volume, the stack trace includes a frame above and below each crossing of a module or protection domain boundary; a single ... replaces intermediate frames within the same module and domain. At the position in the trace of the protection domain that failed the policy check, a line is inserted with the domain's code source and principals, such as >> sqlj:examples [PLPrincipal.Sandboxed: java] <<. This abbreviated trace should be well suited to the purpose of determining where any additional permission grants ought to be made.

    Because each check that is logged is then allowed, it can be possible to see multiple log entries for the same permission check, one for each domain in the call stack that is not granted the permission in the normal policy.

    About false positives

    It is not uncommon to have software that checks in normal operation for certain permissions, catches exceptions, and proceeds to function normally. Use of this policy, if it is configured to grant the permissions being checked, will produce log entries for those 'hidden' checks and may create the appearance that permissions need to be granted when, in fact, the software would show no functional impairment without them. It is difficult to distinguish such false positives from other log entries for permissions that do need to be granted for the software to properly function.

    One approach would be to try to determine, from the log entries, which functions of the software led to the permission checks that were logged, and specifically test those functions in a database session that has been set up with a different policy file that does not grant those permissions. If the software then functions without incident, it may be concluded that those log entries were false positives.