[
https://issues.apache.org/jira/browse/DERBY-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647633#comment-13647633
]
Rick Hillegas commented on DERBY-6160:
--------------------------------------
The "callAbort" permission is granted
o ...to derby.jar if you are running embedded
o ...to derbyclient.jar if you are running client/server
Note that there are 3 policy files which must be considered:
1) The policy file you use when running embedded. This is described by the
Developer's Guide.
2) The server-side policy file you use when running client/server. This is
described by the Admin Guide.
3) The client-side policy file you use when running client/server. I can't find
where we document this policy file.
We ship a server.policy file with the product. This is the default,
overly-broad policy file used for case (2) if you bring up a server without
specifying your own, customized policy. This default policy file includes a
block of permissions for derbyclient.jar. Ordinarily, you wouldn't include
these derbyclient.jar permissions in a server-side policy file. We could
probably remove these permissions from server.policy. However, I suppose these
permissions make sense if your application runs server-side and needs to
connect across the network to another Derby server.
The template.policy file contains examples of permission blocks which would go
into (1) , (2), or (3).
There are four kinds of permissions which are granted to Derby:
i) Mandatory, hard-coded permissions. These are permissions which you need to
include, uncustomized, in the appropriate policy file. These permissions must
be granted if you want Derby to run at all. These include the permissions which
are called "Mandatory permissions" in the "Granting permissions to Derby"
section of the Developer's Guide.
ii) Mandatory, customizable permissions. These are permissions which need to be
included in the appropriate policy file but which the customer needs to tailor
to the environment. These permissions must be granted if you want Derby to run
at all. These include the permissions which are called "Database access
permissions" in the "Granting permissions to Derby" section of the Developer's
Guide.
iii) Optional, hard-coded permissions. You can omit these permissions in order
to tighten your security. However, if you omit these permissions, then some
Derby features may not work.
iv) Optional, customizable permissions. These are like (iii) but need to be
customized to your environment.
The "callAbort" permission is an example of (iii) which you would include in
(1) or (3) as necessary.
Hope this is useful,
-Rick
> Fixes needed to documentation topics on security policy permissions
> -------------------------------------------------------------------
>
> Key: DERBY-6160
> URL: https://issues.apache.org/jira/browse/DERBY-6160
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.9.1.0, 10.10.1.1
> Reporter: Kathey Marsden
> Assignee: Kim Haase
> Attachments: DERBY-6160-2.diff, DERBY-6160-2.stat, DERBY-6160-2.zip,
> DERBY-6160.diff, DERBY-6160.stat, DERBY-6160.zip
>
>
> DERBY-5363 added a new required permission RuntimePermission
> "accessUserInformation".
> This should be added to the developer guide information under granting
> permissions to Derby.
> https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/devguide/cdevbabejgjd.html
> I am not sure of the context under which it is required if it is just needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
