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

Omair Majid omajid at redhat.com
Wed Jun 8 13:54:40 PDT 2011

On 06/08/2011 04:51 PM, Deepak Bhole wrote:
> * 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.

Agreed. I still wonder, though, if isSigned() is the right thing to use. 
Don't we want code in doPrivileged() block to be able to access 
persistence service for any url? Or Do we want unprivileged code called 
by a signed application to access any persistence service?


More information about the distro-pkg-dev mailing list