Use hard links to link sysroot files within ModuleCache because sym links on Windows require SE_CREATE_SYMBOLIC_LINK_NAME privilege enabled.
Diff Detail
Event Timeline
Even with this check, creating the symbolic link might still fail for other reasons related to the filesystem and not related to security. Would it be better to just try to create it no matter what and log the error if it fails?
I believe calling EnableCreateSymLinkPrivilege might be beneficial anyway since as I can tell from running "whoami /priv" that SE_CREATE_SYMBOLIC_LINK_NAME is disabled by default . I'm somewhat concerned that we may call FileSystem::Symlink when we 100% confident that it will fail. As an alternative, we may just call FileSystem::Symlink anyway but always ignoring its result...
Please let me know your opinion.
Hmm, yea that's not a bad idea. Let me look into the privilege thing a
little tomorrow. In the meantime, do we properly handle the error case
anyway (at least it should print a log and not have unexpected behavior).
Creating the symlink could fail on other platforms too, not just windows
Consolidated all logic that pertains to sysroot management in CreateHostSysRootModuleSymLink.
Is there really no other way to create something akin to a symlink on windows? How can you have control over a directory and yet not be able to create links? Is there any other kind if link? Alias? anything? Seems weird to be able to create files but not create links in a directory you have created?
Would a .lnk file work? I think the Windows API should contain functions to
create/resolve those.
It really depends on what you mean by control. NTFS's security complicated is far more granular than that of other file systems. That said, Windows has many different types of links. Only symlinks have this restriction, and I don't know why it is the way it is. It looks like this whose target is a file. If that is the case, you might consider using a hardlink instead. There are no special privileges required to create a hardlink on Windows. You could even have it use a hardlink on windows and a symlink on other platforms, if that seems better.
I think this is the easiest and most-likely-to-work-in-the-most-scenarios approach as long as it works for what you need. What do you think Oleksiy?
.lnk files are only understood by the shell, not by the file system. So you can execute a link file by calling ShellExecute (a shell function), but you can't CreateProcess (a system call) on one. You can manually resolve one, but as youc an see from looking at this code, it's not exactly a fun thing to do: https://msdn.microsoft.com/en-us/library/windows/desktop/bb776891%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#Shellink_Resolving_Shortcut
If hard links don't need any security requirements it should be ok. I can create new call FileSystem::Hardlink (with use of link call in Posix and CreateHardLink on Windows) and switch my code to use it instead of SymLink.
Looks good. Glad we avoided getting all that token stuff into LLDB. I suspect we may need to do that in the future for other reasons, but it's scary stuff so I'm glad we can hold out a little longer.
AFFECTED FILES
/lldb/trunk/include/lldb/Host/FileSystem.h /lldb/trunk/source/Host/posix/FileSystem.cpp /lldb/trunk/source/Host/windows/FileSystem.cpp /lldb/trunk/source/Utility/ModuleCache.cpp /lldb/trunk/source/Utility/ModuleCache.h
USERS
ovyalov (Author)