Berin Loritsch wrote:
>
>
> Steve Brewin wrote:
>
> > 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.
This is exactly my understanding and exactly how I have defined the policy
statements. I'm testing using James and maybe this is complicating matters.
What I will do is write a simple application that explictly accesses
resources protected by policy statements so as to take James out of the
equation.
Winds willing, I'm off sailing tomorrow, so this will not be until Monday.
>
>
> 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.
Yes, and "action" _singular_ does not parse. The docs. are incorrect in this
respect.
Thanks for your help, I'll get back to you on Monday.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
