[rfc][icedtea-web] Reflectively add URLPermission to SecurityDesc if available

[Andrew Azores]

On 07/17/2014 02:38 PM, Omair Majid wrote:
> * Andrew Azores <aazores at redhat.com> [2014-07-17 14:30]:
>> I don't know
>> what happens for eg ftp. No port restriction perhaps? It's not clear from
>> the documentation I've seen, but I wouldn't expect it to mean the permission
>> has no effect, so I suppose it's no port restriction (unfortunately).
> Maybe not add one for ftp until we have a bug report?

Well, there's nothing being added that explicitly handles any particular 
protocol. I'm just much less sure about what happens with eg ftp than 
for http(s), because the documentation just doesn't seem to specify.

>
>> So here are some examples of what the results *should* look like in a few
>> cases.
> These look great! Thanks for taking care of this!
>
>> * Case F - applet with no JARs... not sure what to do about this one
>> codebase = http://example.com/applet
>> host = http://example.com
>> resources = [ http://example.com/applet/app.class ]
>> permissions = [ ]
>>
>> Any ideas on what to do for case F? Perhaps as well as iterating over all
>> the JARs' locations I should also add the JNLPFile's getCodebase()'s host
>> with its default port - but this could end up adding an extra permission
>> that shouldn't actually need to be there?
> That seems like the right thing to do.

-8 patch attached with this added, no other changes.

>
>> And any ideas on how to write
>> reproducers for this? Should I just make a simple reproducer that attempts
>> to make some bogus connection on a non-default port, for example, and check
>> that it fails (this would cover Case A)?
> Yeah. But make sure the failure is caused by the URL permission, not
> because the resource is not actually there. Jiri might have better idea
> about reproducers, though.
>
>> I've already included some unit
>> tests for the simple URI manipulation stuff. I was thinking of adding some
>> tests using dummy JNLP files and exposing SecurityDesc#getUrlPermissions()
>> as package-private to be able to better test the expected results in the
>> Cases above, but this would mean that the SecurityDescTest would also need
>> to do the same reflection to determine if URLPermission is available. Should
>> that be done?
> That sounds like a bit of a mess. Maybe the test is not worth having if
> it's hard to read/write/debug.

Yea, it definitely would be a bit of a mess.

>
> Patch itself looks okay.
>
> Thanks,
> Omair
>

I'll wait for Jiri's word on the reproducers then. Once I figure out how 
I'm going to tackle that then I'll also include an updated 1.5 backport, 
but that's really just going to come down to removing 
ReflectiveOperationException and producing some nasty try/catches again 
instead.

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: urlpermissions-8.patch
Type: text/x-patch
Size: 16914 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140717/54693c86/urlpermissions-8.patch>