Skip to main content

ACC Client's Permission

4 replies [Last post]
isana
Offline
Joined: 2005-11-10

Hello,

My client application gets the following security exceptions when it's invoked via Java Web Start.
--- CASE1: Caused by ImageIO
java.security.AccessControlException: access denied (java.io.FilePermission C:/Temp/users/xxxx/imageio18686.tmp delete)
---
--- CASE2: Caused by System.getProperties()
java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
---
I guess that Java Web Start's security sandbox causes these exception. Of course, in CASE1, the OS user has sufficient OS permission to delete the file.

Then, how to allow the client to access files and System.getProperties()?

I thought that I should give it permissions by writing JNLP file with . But the client's JNLP file is generated by GlassFish, and I don't know how to tell GlassFish to include element in the generated JNLP file. (In addition, generated JNLP file has element already?).

Then, the developer guide of GlassFish mentions client.policy file, and I thought that it could be an answer.

https://glassfish.dev.java.net/nonav/javaee5/docs/DG/beakt.html#fvymy

But it's not clear for me with the document that...
- should I edit GLASSFISH_HOME/lib/appclient/client.policy?
- or should I include custom client.policy somewhere in EAR archive?

Any help is appreciated.

Thank you.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tjquinn
Offline
Joined: 2005-03-30

Great question.

There is a way to specify an alternate policy to use for a particular Java Web Start app client launch. Before I get to that, though...

Does the client behave as you expect if you use the [i]appclient[/i] command?

In the second case you described in your post are you certain that the client is only [b]get[/b]ting property values and not trying to [b]set[/b] any?

Here's the background. An app client launched via the GlassFish Java Web Start feature should receive (by default) the same permissions as if it were run using the [i]appclient[/i] command. You can see what these settings are either by looking in the GlassFish source (if you have downloaded it) at appserv-core/src/java/com/sun/enterprise/appclient/jws/boot/jwsclient.policy or look in the appserv-rt.jar file in ${GlassFish-publish-dir}/lib for an entry with the path com/sun/enterprise/appclient/jws/boot/jwsclient.policy.

This policy file should be functionally equivalent to what is used for app clients run with the [i]appclient[/i] script. The difference is that there are some placeholders used to specify codebases to account for the caching that Java Web Start does with downloaded jar files.

You'll see that the permissions grant all code (including your client code) permission to read properties but not write them. That's why I asked above if the client might be trying to write properties.

As for problems deleting the file, the default permissions allow client code to read and write files on the local file system -- but not delete.

[The GlassFish documentation (and the doc for the Sun Java System Application Server product) tells how to use alternate policy settings for clients started with the [i]appclient[/i] script.]

To specify different policy settings for a client launched using the Java Web Start feature, start by making a separate copy of the jwsclient.policy file. You can extract it from the appserv-rt.jar file if you do not have the GlassFish source handy or just go to the GlassFish source area and retrieve that one file. Then edit that file to suit your app client's needs.

To use your policy you add a bit to the URL you use to invoke the client. When you invoke the client, add to the URL a query string that looks like this:

http://:
/?arg=-jwsPolicyTemplate&arg=

(This makes use of the general mechanism for passing arguments via the Java Web Start app client launching technique.) The argument jwsPolicyTemplate is handled by the GlassFish app client container and is not passed to your client.

Make sure the URL resolves to your customized policy.

As an aside, you correctly pointed out that the generated JNLP document already specifies all permissions. But that applies only to the GlassFish project code that starts up the app client container (ACC) when launched via Java Web Start. Java Web Start applies the all-permission setting to code specified by that JNLP document only, which is actually very little code. All other code is specified by other JNLP documents that the main one refers to, and those other JNLP documents do not grant all permissions so access can be controlled using the policy. We chose to do it this way so app clients would behave the same whether launched using Java Web Start or using the [i]appclient[/i] script.

I know this is a long response, but I hope it provides enough information to resolve the problem. Please post again and report the outcome!

- Tim

isana
Offline
Joined: 2005-11-10

Thank you very much, Tim.
And I'm sorry for late response.

The way you suggested successfully fixed my trouble. And your detailed explanation let me understand things well.
Thank you.

It's enough fine to get custom policy from URL-pointed place. But I feel that it'll be better to give users more easy alternative such as placing custom policy file in EAR or client JAR file, because developers can control which policy file is applied to the client at deployment time (but, there could be a security problem in this way...).

I'd like to answer your question:

> are you certain that the client is only getting property values and not trying to set any?

The client never calls System.setProperty(). And probably it does not call setProperty() method of any Property instances.

The following is a part of the exception's stacktrace:
---
java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertiesAccess(Unknown Source)
at java.lang.System.getProperties(Unknown Source)
at MY.CLIENT.CODE.main(MyClient.java:72)
---
It seems that System.getProperties causes the exception.

Giving 'write' permission by custom policy file stopped the exception above.

> Does the client behave as you expect if you use the appclient command?

I'm sorry, but I didn't try appclient command.

Thank you.

tjquinn
Offline
Joined: 2005-03-30

> It's enough fine to get custom policy from
> URL-pointed place. But I feel that it'll be better to
> give users more easy alternative such as placing
> custom policy file in EAR or client JAR file, because
> developers can control which policy file is applied
> to the client at deployment time (but, there could be
> a security problem in this way...).

Perhaps in a future release the sun-application-client.xml descriptor could support a new subelement under java-web-start-access that gives a URI (relative to the containing archive) to the policy file to use.

More generally, there are many ways developers and administrators might want to customize the Java Web Start support, and for each of those probably several ways of doing it. We are very interested in hearing what people's needs are in this area. Thanks for sharing yours.

>
>
> I'd like to answer your question:
>
> > are you certain that the client is only getting
> property values and not trying to set any?
>
> The client never calls System.setProperty(). And
> probably it does not call setProperty() method of any
> Property instances.

Oh, yes. Now that I read your message more carefully I see that the client invokes System.getProperties() to get all of them. I had misread that and was thinking it was invoking System.getProperty().

The source code for System.getProperties() does indeed check for read and write permission and the JavaDoc for the method says this as well. You could avoid this issue by invoking System.getProperty for each property the app client needed instead of getting all the system properties in a single invocation of getProperties. It would be more cumbersome that way but it would avoid the need to tailor the policy - at least for retrieving the property values you are interested in. I realize you have the file deletion problem to deal with anyway, so you need a custom policy for that.

> I'm sorry, but I didn't try appclient command.

It probably would behave the same anyway, given what the underlying cause it.

- Tim

isana
Offline
Joined: 2005-11-10

Thank you, Tim.

> JavaDoc for the method says this as well.

Oh, yes, I found the description. I should read more carefully the document. I'm sorry.