[rfc][icedtea-web] policytool in itweb-settings

[Andrew Azores]

On 01/14/2014 10:34 AM, Jiri Vanek wrote:
> On 01/14/2014 03:16 PM, Jacob Wisor wrote:
>> On 01/14/2014 01:42 PM, Jiri Vanek wrote:
>>> On 01/14/2014 12:33 AM, Jacob Wisor wrote:
>>>> Hello there!
>>>>
>>>> On 01/13/2014 11:20 PM, Andrew Azores wrote:
>>>>> Hi,
>>>>>
>>>>> This small patch hooks the JDK policytool into itweb-settings. It 
>>>>> can then be
>>>>> used to set up a custom user-level JNLP policy - this, in 
>>>>> combination with the
>>>>> Run in Sandbox patch, will allow for quite a lot more flexibility 
>>>>> in how
>>>>> permissions are handled with signed applets/applications.
>>>>>
>>>>> A nicer, more user-friendly editor to replace the policytool will 
>>>>> hopefully come
>>>>> later on.
>>>>
>>>> Oooooooh yes, please! This would be awesome! :-)
>>>
>>> Yes this would be :))
>>> But it is different task. And Quite complex. Especially it must pass 
>>> upstream
>>> (openjdk). And that is *the* task!
>>
>> Well, it does not need to replace or displace OpenJDK's policytool. 
>> It should be probably enough
>> that it complements it. ;-) You know, it's neither forbidden nor 
>> against any spec to build
>> augmenting tools around OpenJDK.
>
> But still contribute to Openjdk itself is the right thing to do.
>
> ...
>>
>> At first, I thought that the problem would rather be that some system 
>> configurations may be missing
>> a PATH environment variable entry to policytool and thus launching it 
>> may fail. But, Jiri is right.
>> The best approach here would probably be to call directly into 
>> policytool's main() method with
>> user.home as its current working directory. policytool is part of 
>> rt.jar, not tools.jar, so it
>> should already be on bootclasspath. But, you may have to investigate 
>> deeper into it because the
>
> Great!
>
> But I doubt "with  user.home as its current working directory" is 
> possible.
> Or do we misunderstand each other?
>
> I had in my mind simple PolicyTool.main(arg,aerg,arg) call in 
> itw-settings.
>
>
>> package names of some tools have changed from OpenJDK 6 over to 
>> OpenJDK 7.
>
> I doubt policy tool was touched in last 10 years ;)
>
> J.
>

New patches attached. There are two testcases in the included reproducer 
- one tests to ensure that without a custom policy, unsigned applets 
can't read user.home from the system properties. The other testcase 
installs a custom policy allowing just that, and then ensures that all 
the same applets are now able to perform this action. And of course 
there's some backup/cleanup stuff going on in BeforeClass/AfterClass 
methods in the tests as well.

The actual PolicyPanel is now launching the PolicyTool by invoking its 
main method, rather than exec'ing a new process. I've put this into a 
new thread, but tbh I'm not sure if that was entirely necessary. The 
"View Policy" button has a tooltip now that indicates the location of 
the file that will be opened, although this is also displayed in the 
policytool itself if you launch it. The View Button's action listener is 
no longer an anonymous inner class, since I don't really mind the style 
either way personally. Its implementation does have an anonymous inner 
Runnable inside its Thread, though. Oh, and there's also now an error 
dialog if for some reason the policy file can't be opened (eg it exists 
but you don't have read permission, or it exists but is a directory, or 
whatever). If the file doesn't already exist then we attempt to create a 
blank one there first, since the PolicyTool itself doesn't seem to do this.

Oh, and I've left the PolicyPanel as public and non-final, just because 
that's how the rest of the ControlPanel components are. It could very 
well be given default visibility and made final, but I think it might as 
well just be left the same as the rest of the code there.

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom_policy2.patch
Type: text/x-patch
Size: 9034 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140114/95371995/custom_policy2-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reproducers.patch
Type: text/x-patch
Size: 25434 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140114/95371995/reproducers-0001.patch