On Fri Feb 16 19:50:06 2024 +0000, Gabriel Ivăncescu wrote:
But why? What's wrong with accessing the file system?
If stdout is a symlink, how is that different from stdout being the
target of the symlink? Why is returning the latter the wrong thing to do? Why is it our job to do that instead of letting the app decide? I mean I don't know what you want me to answer, I'm trying to make it as simple and less burden on our side as possible so we don't have any extra things to worry about? Here's another one: Let's assume the user *does* decide to redirect output to a symlink. Why should we only go one level deep? Why not loop calling readlink until we find a non-link? Calling it once seems arbitrary to me. See what I mean? Specifically, calling it once also is **different behavior** across platforms, because on Linux it **won't** be dereferenced, while on those with F_GETPATH it will.
Why is this a meaningful race? If you assume that the filesystem can
be modified, how can a program do *anything* meaningful with the output of GetFinalPathNameByHandle(), *ever*? Sorry I don't quite understand what you mean here. Of course things can happen, and apps can do anything they want with the filename; they can also check if it still exists and whatnot. Why is it our business to do that on behalf of the app? Sure, this race isn't particularly common, it was just off the top of my head. But I just don't get why must we compromise "correct" behavior here and get headaches later?
How is there any "correct" behaviour in this situation? This patch is addressing a scenario that doesn't appear on Windows and has no analog, it's the case where a Unix fd, not opened by Wine, is used as a standard handle for a Wine process. Why is returning the symlink path "right", and the real path "wrong"? Why does it *matter* which path you return, when they're fundamentally the same file?
Why is this a meaningful race? If you assume that the filesystem can be modified, how can a program do *anything* meaningful with the output of GetFinalPathNameByHandle(), *ever*?
Sorry I don't quite understand what you mean here. Of course things can happen, and apps can do anything they want with the filename; they can also check if it still exists and whatnot. Why is it our business to do that on behalf of the app?
Sure, this race isn't particularly common, it was just off the top of my head. But I just don't get why must we compromise "correct" behavior here and get headaches later?
A link can be changed under someone's feet, but the same thing is true of *any* file path. Why does the first race matter, and the second part doesn't?
As far as I can see, there is no race that you can come up with related to dereferencing a symlink, that doesn't exist already *anyway* in some other form. Trying to fix a race is only useful if the race can't be triggered some other way.
Unless I'm missing something, the only way an application can safely use GetFinalPathNameByHandle() at all is if they assume the file system won't be changed. That's not to say that's a bad assumption—maybe it's their own config folder, and the user decides to mess with that while the application is running then she gets to keep the pieces. But if you assume that the file system won't be changed, then *no* TOCTOU races matter at all.