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

[Omair Majid]

* 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?

> 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.

> 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.

Patch itself looks okay.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681