8221852: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time

Brian Burkhalter brian.burkhalter at oracle.com
Tue Apr 9 16:40:45 UTC 2019


> On Apr 6, 2019, at 11:01 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/04/2019 23:47, Brian Burkhalter wrote:
>> 
>> Well, after all I put together a different patch [A]. This reverts the native file to the version before the patch for 8218418. It moves all logic of the previous option 2 out of native code and out of the dispatcher code. The main change is the addition of WindowsLinkSupport.CreateSymLink(). The use of WindowsNativeDispatcher.CreateSymbolicLink() is replaced by this method in WindowsFileCopy and WindowsFileSystemProvider. There is also no change applied or needed with respect to obtaining more information about the OS version (build number).
>> 
> I think it will error prone/confusion to have CreateSymLink in one source file and CreateSymbolicLink in another, it might be simply e to just move the the NOT_HELD handling into WindowsNativeDispatcher.CreateSymbolicLink.

Done [1]. Desired behavior manually verified:

* Windows 7 - ERROR_PRIVILEGE_NOT_HELD
* Windows Server 2016 (build 14393) - ERROR_PRIVILEGE_NOT_HELD with Dev Mode on and off
* Windows 10 - ERROR_PRIVILEGE_NOT_HELD with Dev Mode off, success with Dev Mode on

CI tiered sanity tests succeeded.

> More medium term, we need to bring back the OS version detection in WindowsFileSystem so that it can set flags as to what features are supported depending on the OS version at runtime.

I concur that it might be a good idea to make more precise version information available in the Java layer for other purposes, but I am not convinced that using it to determine whether to set this particular flag is any better than the fail-over this patch implements. The build number 14972 as of which this flag is supposed to be supported is rather casually documented [2] and we have no means of actually verifying this in testing. I think the existing logic while ugly is more robust. The issue of course can be revisited at the appropriate time.

Brian

[1] http://cr.openjdk.java.net/~bpb/8221852/webrev-option-2.02/
[2] https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#DXz6icKZOkEozgYR.97
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190409/c74873ce/attachment-0001.html>


More information about the nio-dev mailing list