Symlink CAN be created with wsl started with non-Admin PS but result differs from one created as Admin #8586
Description
Version
0.61.8.0
WSL Version
- WSL 2
- WSL 1
Kernel Version
5.10.102.1
Distro Version
Arch
Other Software
No response
Repro Steps
Start wsl with a non-Admin PS (Windows Terminal), make a symlink (ln -s) of relative path under a drvfs mount (e.g. /mnt/d/)
Expected Behavior
The symlink can be used just like one that is created when wsl is started with a Admin PS (Windows Terminal)
Actual Behavior
When the symlink is attempted to be used on the Windows side with builtin stuff (File explorer / PS / ...), access is denied UNLESS e.g. the accessing PS is an Admin one (yes, non-Admin created symlink can only be accessed as Admin, instead of the other way round).
However, if I try to use it in msys2, the symlink worked as expected. Similarly, if I try to use it in wsl, it worked as expected regardless of whether the wsl is started in an Admin PS.
When I check symlinks created in the two respective cases with fsutil reparsepoint query, the one created as non-Admin does not have the Symbolic Link tag value (but only Microsoft and Name Surrogate). Also the reparse data length and format looks quite different.
I'm not sure if this is a bug / regression or some "intentional fallback approach" (i.e. yet another kind of non-standard symlink that is not "WSL symlink" is created in the non-Admin but relative-path case), but even if it is the latter case, IMHO it would be a really bad idea. ("WSL symlink" itself is awful enough, let alone an additional kind that is semi-accessible.)
Diagnostic Logs
No response