FileSystemProvider

Michael Hall mik3hall at gmail.com
Sun Aug 1 15:17:40 UTC 2021



> On Apr 30, 2021, at 11:17 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/04/2021 01:13, Michael Hall wrote:
>> :
>> 
>> The error is if -Djava.security.manager and -Djava.security.policy are used in invocation….
>> 
>> 
> Thanks for the bug report. It's in JBS as JDK-8266345. I think this is another case where the PolicyFile code needs to be very defensive as opening the policy file is a privileged operation. Also interposing on the default file system provider sets up a sandwich where the PolicyFile is going through untrusted code to get to the file system. Getting all these pieces to work together may require the PolicyFile code to use the built-in file system provider directly, needs more investigation.
> 
> -Alan

An older one. I was just thinking on this though. My own Default provider is pretty much pass through. I think it was required for me to add my own attribute classes. If these attribute classes could be added directly to the existing platform Default I could eliminate the need to override provider. This might eliminate some of these security concerns and startup timing issues. Possibly there might be other security concerns for Default extensions (plugins?). But it would get me out of the startup process. 
I haven’t double checked yet to see if I could figure out a way to do so now without jdk changes.


More information about the nio-dev mailing list