Not using signers in JNLPPolicy.getPermissions()

[Omair Majid]

On 01/04/2011 04:05 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com>  [2010-12-17 18:07]:
>> Hi,
>>
>> I noticed this line in JNLPPolicy.getPermissions(CodeSource source):
>>
>> CodeSource appletCS = new CodeSource(JNLPRuntime.getApplication().getJNLPFile().getSourceLocation(),
>> (java.security.cert.Certificate[]) null);
>>
>> I understand that we need a URL to the actual source of the code
>> (instead of a url to the on-disk cache), but why use null as the
>> certificate array? Is there a reason we are not using the actual
>> signers associated with the CodeSource?
>>
>
> appletCS is used only in the getPermissions call below, whose return is
> merged with the permissions that the jar code signer has
> (clPermissions).
>
> clPermissions already accounts for code-signer specific permissions, so
> providing signers to the CodeSource constructor would make no
> difference, and was probably done to avoid redundant merging.
>

Thanks for the explanation. However, I still dont think this code is 
entirely correct. clPermissions (as far as I can tell) does not account 
for system policy. If the system's policy file contains something like:

grant signedBy "Duke" {
     permission java.io.FilePermission "/tmp/*", "read,write";
};

And the applet is signed by Duke, the code wont be granted these 
permissions (but like other signed code, it will be granted 
AllPermissions - unless a policy file is used to grant it a subset of 
permissions rather than all permissions).

Cheers,
Omair