1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set

[Andy Koppe]

On 11 August 2010 14:55, Corinna Vinschen wrote:
>> there's no Win32-safe way to set a new
>> directory handle as cwd in Vista and later anymore.  Since there's no
>> official API to set the cwd using a directory handle, there's no way to
>> set the Win32 cwd to a directory with restricted permissions.
>> This *is* frustrating.
>>
>> I'll look into another solution.  Probably we will have to call
>> SetCurrentDirectory again and ignore any error.  I don't accept the
>> aforementioned restriction for POSIX calls.
>
> I'm wondering what you say about this.  From John's description I take
> it that the construct really is unsafe, and we can't discount the chance
> that this race can break Cygwin itself in some scenarios.
>
> Since SetCurrentDirectory appears to be the only valid way to change the
> Win32 CWD in Vista and later, I think we should do so as well.
>
> This means, the Win32 CWD will be wrong as soon as
>
> - The path is not accessible to admins w/o backup privileges.
>
> - The pathlen is > 259.

Why did they ever bother with long path names if fundamental stuff
like that doesn't work?


> The latter is already true anyway since no tinkering with internal
> Win32 structures will allow that.  At least the pathname in the PEB
> is wrong, just the handle was correct so far.
>
> That also leads to the question what to do in these cases?
>
>  1) Return with error
>
>    --> Disallows these paths in Cygwin's POSIX API as well.  Not an
>        option, IMHO.
>
>  2) Just ignore that SetCurrentDirectory failed?
>
>    --> Win32 CWD == previous CWD.
>
>  3) If SetCurrentDirectory fails, call
>
>       SetCurrentDirectory (GetSystemDirectory ())
>
>    That's basically what CMD.EXE does if it can't handle the current
>    CWD at startup.  You can easily test that by setting the CWD to a
>    network UNC path and start CMD.EXE.
>
> I think option 3) is what we should use, but I'm open to other
> suggestions.

I agree with approach 3, but could we send it somewhere safer? Ideally
somewhere that isn't writable. I'm concerned about the damage that a
process that thinks it's elsewhere could do to the system32 directory.

Andy