Berin,
Thank you for your reply. I have been on vacation, hence the slow response.
For now, I don't even see where in the source code java.security.manager does anything.
Me neither, but as there is an example of <policy> stanzas in the environment.xml documentation I am assuming that this can/does/did work.
Try changing the definition of PHOENIX_SM to be like this:
SET PHOENIX_SM="-Djava.security.manager="
No difference I'm afraid. Any further ideas welcome! Can you apply a policy in your configuration?
I found the code that creates the policies, and they are applied to codebases. Can you share your environment.xml file?
From everything I can see, it should work right out of the box.
The code that starts the ball rolling looks like this:
public void configure( final Configuration configuration )
throws ConfigurationException
{
setupDefaultPermissions();final Configuration[] keyStoreConfigurations = configuration.getChildren( "keystore" );
final HashMap keyStores = configureKeyStores( keyStoreConfigurations );
final Configuration[] grants = configuration.getChildren( "grant" );
if( 0 != grants.length )
{
configureGrants( grants, keyStores );
}
else
{
final String message =
REZ.getString( "policy.notice.full-perms" );
getLogger().info( message );
final Permissions permissions = createPermissionSetFor( getInclusiveURL(), null );
permissions.add( new java.security.AllPermission() );
}
}
This configures the keystores, and then determines if there is a set of <grant/> elements. If not, the java.security.AllPermission() set is used. Otherwise it goes through and sets up the policy sets for each <grant/> element.
Your <grant/> blocks should look like this:
<grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
key-store="foo-keystore">
<permission class="java.io.FilePermission" target="/tmp/*"
actions="read,write" />
</grant>The attributes are not necessary, but they are used to get an array of Certificate objects each representing a signer. The base permissions are set on a new CodeSource( URL, Certificate[] ) (aka code-base URL and the set of signers). All permissions defined in the <grant/> go toward that CodeSource.
The <permission/> elements have one absolutely required attribute: "class". The list of attributes follow:
class == The class name of the Permissions object being configured.
actions == The comma separated list of actions to be granted (i.e. read,
write, etc.)
signed-by == used for the same purpose as the <grant/> above
key-store == used for the same purpose as the <grant/> above
target == The target name that the permission applies to (can be a path,
URL, etc.)The "actions" and "target" parameters are used to create the Permission object. It has to follow the following contract:
If no target or actions, then it must have an empty constructer. If only a target and no actions, then it can have a constructor that accepts one string (the target). If both are specified, then the permission object must have a constructor that accepts two strings (target, actions [in that order]).
NOTE: if there are signers associated with the permission, then the definition
here will be turned into an UnresolvedPermission with all the associated
information included.
THe important thing for your <permission/> entries is to make sure the "actions" attribute is "actions" *plural*. If the docs use "action" _singular_ then it is a mistake.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
