On Fri Feb 16 20:37:37 2024 +0000, Zebediah Figura wrote:
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.
Hilariously, I just tested, and if you use a symlink as a standard handle to a Linux program, /proc/.../fd/ points to the target *anyway*.