The future of policytool?

Jiri Vanek jvanek at
Tue Oct 21 12:50:16 UTC 2014

On 10/21/2014 09:47 AM, Wang Weijun wrote:

I have added also distro-pkg-dev list as it is main list for IcedTea-Web (itw) development.

> Hi All
> We are defining fine details of JDK module graph and encounter the policytool program. It is now included in JRE and depends on the java.desktop module. Our understanding is that very few people is using the tool but we are not sure how it is used. Therefore I am writing this mail asking for your suggestions on the future of it.
> Are you (or someone else you know) still using it? If yes, do you use it from JRE or JDK? Is it a must for you?
> Even if you are not using it, any feedback is still welcomed.
> - Do you think it should stay in JRE?
> - Or should it stay in JDK? Do you want it in jdk/bin?
> - Or do you think the function should be a part of IDE and not in JDK?
  definitely not
> - Or do you think it's just useless?
  Except creating of custom policy tool, I have never used it in real life. (Except cases when showing students how "pure awt" can look like :)
> Thanks
> Max


Thank you for this email.

I think icedtea-web is one of few projects which is using various runtime policies really heavily. We used policy files to set up special rules for signed apps - eg to forbid those to touch filesystem or similar.
And what is better tool for editing policy files the upstream editor? See

However, I think we all agree that usage of policytool is painful, and one have to know at least a bit about java and computers generally be able to put record into it.
That is why we created custom PolicyEditor - - It allows us to edit policies in runtime, and/or to create permanent policies in simple, mouse driven way.
The drawback of clickable tool is that it is not allmighty.  If somebody needs to tune the policies really detailed, we offer "execute policytool" button, and we are closing our mini-tool and using policytool in furhter editation of temp/permanent policies.

If policytool will  be removed, we will have to revisit this approach. And remove support of upstream editor at all.


More information about the security-dev mailing list