Module URL

David M. Lloyd david.lloyd at redhat.com
Wed Apr 7 18:27:25 PDT 2010


If it helps, I have implemented something similar.  I use a module scheme 
like this:

     module:<group>:<name>[:<versionSlot>][/resource/root][?resource/path]

and in the case of code source, we use just the module identifier part (up 
to and including the optional version slot).  Thus, code source is defined 
in terms of the module only, with no relationship to where the code 
actually came from (i.e. the module loader is trusted).

On 04/07/2010 03:58 PM, Sean Mullan wrote:
> Mark Reinhold wrote:
>>> Date: Wed, 07 Apr 2010 15:37:50 -0400
>>> From: sean.mullan at sun.com
>>
>>> We need to retain the URL of the repository from which a module was
>>> retrieved
>>> to properly construct the CodeSource and ProtectionDomain for classes
>>> in that
>>> module. Is this information stored somewhere in the library?
>>
>> No, not at the moment.
>>
>> In general a module may be downloaded from a repository other than the
>> one in which it was originally published, and modules from different
>> repositories may need to wind up in the same protection domain.
>>
>> Can't we just leave the CodeSource location property unspecified, i.e.,
>> null?
>
> Hmm. In the signed module design, we are binding the granted permissions
> to the module at installation time. So it should be possible to simply
> instantiate the ProtectionDomain with an unspecified CodeSource and a
> static set of granted permissions at runtime. Will need to look into
> that more.
>
> However, in some cases we'll need the URL at install time for security
> purposes. Unsigned modules packaged as web applications will need to be
> sandboxed. Network access is by default limited to connections back to
> the host, and is based on the CodeSource URL (see
> URLClassLoader.getPermissions(CodeSource)). What URL should I use in
> that case in order to grant a SocketPermission to that unsigned module?
>
> --Sean

-- 
- DML ☍



More information about the jigsaw-dev mailing list