Opened 6 years ago
Last modified 3 years ago
#18680 new enhancement
Create symbolic links in shared folders without administrator priviledges using new Windows 10 Developer Mode
Reported by: | asmala | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 6.0.8 |
Keywords: | symlink | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description
Starting with Windows 10 Insiders build 14972 symlinks can be created without needing to elevate the console as administrator. The prerequisite is to enable Developer Mode, and after that any user on the machine can
- Run the
mklink
command without elevating a command-line console - Use CreateSymbolicLink API if additional dwFlags option
SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
is set to0x2
.
Since even after enabling the Developer Mode VirtualBox has to be run as Administrator in order to create symlinks in shard folders, I assume the method 2 i.e. API calls are used to create them.
My enhancement request: Please add the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
to the API call when creating symlinks to shared folders under Windows 10 so Administrator priviledges are not required when Developer Mode is enabled.
I'd say this is a legitimate issue, and a legitimate request, and one that is probably easily fixed. Fixing it has the benefits that:
Your assumption appears correct; the flag is not anywhere in the code from what I can see. Here is where the call to
CreateSymbolicLink
(actuallyCreateSymbolicLinkA
) is made, in kBuild:https://www.215389.xyz/browser/kBuild/trunk/src/kmk/kmkbuiltin/mscfakes.c?rev=3387#L442
This is the only call to
CreateSymbolicLinkA
and it relies on is_directory which never includes the bit0x2
(i.e.SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
).Documentation for this can be found here: https://docs.microsoft.com/en-gb/windows/win32/api/winbase/nf-winbase-createsymboliclinka?redirectedfrom=MSDN#SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
I expect (but can't verify) that it's safe and reliable and functionally equivalent to always include this bit/flag by default: it should only be observed by Windows if the user has already enabled this in Win10 (otherwise safely returning the same error just as if the bit was not included in the first place)... and it should otherwise be irrelevant and suitably ignored in the "Run as Administrator" case. Older versions of Windows would no doubt safely ignore it too.