This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]