Repository navigation
coreutils: use the executable's name on disk on Windows #16229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
KrushnXGIT
wants to merge
1
commit into
uutils:main
from
KrushnXGIT:windows-case-insensitive-dispatch
+67
−6
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 2 problems with this:
If your
basenameis on disk asBaseName.exe, this will fail to match any commands, becauseGetModuleFileNameWreturnsBaseName.exeand notbasename.exe.More importantly, the comment is incorrect.
GetModuleFileNameWactually returns the value stored in the PE loader and that can be whatever. Technically, it can be truly whatever, but in practice it's whatever you passed toCreateProcessaslpApplicationName.For instance, this is an entirely feasible way to use coreutils:
This PR breaks name lookup, because
GetModuleFileNameWreturnscoreutils.exe.The correct solution is to simply do lowercase hashing which can be trivially implemented. But I would personally be opposed to this. Coreutils aren't just some random Windows tools, and I think it's in the best interest of everyone if they get their (if I may) damn path casing correct. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is expected because we don't consider BaseName as valid name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, we already use
AT_EXECFNto reject hijacked argv[0] . IslpApplicationNamecommonly used?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this is about insensitive filesystem support? In that frame of mind, storing a
BaseName.exeon disk would be equivalent tobasename.exe, would it not?Huh. Yeah, there are actually THREE different issues with the comment. 😄
It is common. In fact, it's the only reason this PR even seems like it would work: CMD sets it to the normalized file path (and so do other Windows launchers).
If you call
CreateProcess("BaseName.exe")naively, thenGetModuleFileNameWsimply returns whatever is inargv[0]that matched a path on disk. It's not normalized.So, actually this PR only fixes CMD (and some others), but then also breaks the inverse scenario, creating problems elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my thought, user should symlink/hardlink as
basename.exe, but it can be called asBaseName.Is there any API doing same things with
AT_EXECFN? If not, I don't agree with this change too.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then the current version might fit that: as lhecker said,
GetModuleFileNameWis the closest thing toAT_EXECFN, so dispatching on it is the same kind of protection as on Linux.lpApplicationName/executable=with a different name gets rejected the same wayexec -ais there, and cmd's casing working is only a side effect. I'd fix the comment, lhecker is right that it isn't the name on disk.@lhecker does that framing work for you, or is there a reason Windows should keep trusting argv[0]?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said, I'm not really familiar with
AT_EXECFNand what it's supposed to do here. If I understood the first 2 paragraphs of #15785 correctly (it's just way way way too long to read in full), I think it's for ensuring that a multicallls.execannot be invoked asecho.exeby manipulatingargv[0]. I'm not sure how valuable that is on Windows, since AppArmor does not exist like that and I suspect the Windows equivalents don't care aboutlpApplicationNamevslpCommandLineanyway.However, if we want to fix that,
GetModuleFileNameWwould be a good replacement forargv[0]. It would not fix the case-sensitivity issue, however.This comment was marked as outdated.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lpApplicationNameis a place to set the binary we want to exec. SolpApplicationName=coreutils.exeis invalid if we installed individual binaries on the system. So I think we should specifylpApplicationName=/path/to/hardlinkand usingGetModuleFileNameWis making a sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me: with individual binaries installed,
lpApplicationName=coreutils.exeplus abasename.exeargv[0] is the same thingexec -adoes on Linux, which we already reject. If @lhecker is fine with that use being rejected, I can reopen this framed asAT_EXECFNparity on Windows, with the comment fixed and no claim about case-insensitivity.