This is an archive of the discontinued LLVM Phabricator instance.

Use hard links to link sysroot files within ModuleCache.
ClosedPublic

Authored by ovyalov on May 7 2015, 4:29 PM.

Details

Summary

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

ovyalov updated this revision to Diff 25260.May 7 2015, 4:29 PM
ovyalov retitled this revision from to Skip sysroot creation by module cache if symbolic links are not allowed for active user..
ovyalov updated this object.
ovyalov edited the test plan for this revision. (Show Details)
ovyalov added reviewers: clayborg, zturner, chaoren.
ovyalov added a subscriber: Unknown Object (MLST).
zturner edited edge metadata.May 7 2015, 4:38 PM

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?

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

ovyalov updated this revision to Diff 25278.May 7 2015, 8:09 PM
ovyalov edited edge metadata.

Consolidated all logic that pertains to sysroot management in CreateHostSysRootModuleSymLink.

clayborg edited edge metadata.May 8 2015, 11:02 AM

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?

chaoren edited edge metadata.May 8 2015, 11:08 AM

Would a .lnk file work? I think the Windows API should contain functions to
create/resolve those.

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?

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?

Would a .lnk file work? I think the Windows API should contain functions to
create/resolve those.

.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

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?

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?

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.

ovyalov updated this revision to Diff 25359.May 8 2015, 12:39 PM
ovyalov retitled this revision from Skip sysroot creation by module cache if symbolic links are not allowed for active user. to Use hard links to link sysroot files within ModuleCache..
ovyalov updated this object.
ovyalov edited edge metadata.

Added FileSystem::HardLink call and switched ModuleCache to use it.

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.

clayborg accepted this revision.May 8 2015, 1:00 PM
clayborg edited edge metadata.

Looks good.

This revision is now accepted and ready to land.May 8 2015, 1:00 PM
ovyalov closed this revision.May 8 2015, 4:59 PM

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)

http://reviews.llvm.org/rL236917