[RFC][IcedTea-Web]: Change #4 (PersistenceService) of new JNLP specification (v7.0)

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2011-06-08 15:59]:
> On 06/08/2011 03:34 PM, Deepak Bhole wrote:
> >* Saad Mohammad<smohammad at redhat.com>  [2011-06-08 15:18]:
> >>Hi,
> >>
> >>This is the patch that allows any trusted application to have access
> >>to any PersistenceService data (including ones from other hosts). It
> >>is part of the new JNLP specification, and is stated under change #4 (http://jcp.org/aboutJava/communityprocess/maintenance/jsr056/jnlp-7_0-changes.html).
> >>
> >>This patch is very simple, it uses a custom method [a modified
> >>version of ServiceUtil.checkAccess()] to validate whether the
> >>current application is trusted and has a signature.
> 
> >
> >Also, is the checkSigned function actually needed? ApplicationInstance
> >has an isSigned() method and if app is not null, you can use it
> >directly..
> 
> I think checkSigned is needed. Weren't you the one who pointed out
> that relying on isSigned() is not enough?
> http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=acaf27f20127
> 

Doh! Hmm, looking at the surrounding code, ServiceUtil.checkAccess() is
callable such that app may be null (when it is called from
JNLPSecuritymanager.askPermission). In that case, denying access is not
the right course since JNLPSecurityManager is the global security
manager and it may very well get a socket permission check call from
outside of app code.

With PersistentService however, app should never be null since no JVM
code should ever be using it.

Cheers,
Deepak

> Cheers,
> Omair