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

[Andrew Azores]

On 01/14/2014 01:16 PM, Andrew Azores wrote:
> 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,
>

Whoops, please ignore 
tests/reproducers/simple/CustomPolicies/resources/ExtensionJnlpTest.html 
in that reproducer patch. I used it as a template and missed cleaning it 
out before making the patch.

Thanks,

-- 
Andrew A