This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 11 Aug 2010 16:50:02 +0200
- Subject: Re: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
- References: <3C031C390CBF1E4A8CE1F74DE7ECAF3A140684F0AA@MBX8.EXCHPROD.USA.NET> <20100811084926.GC26152@calimero.vinschen.de> <20100811135528.GH14202@calimero.vinschen.de> <AANLkTinP-20+GZX0U=ihQL-nrtz2uXE2fM-=fGVHsh89@mail.gmail.com>
- Reply-to: cygwin-developers at cygwin dot com
On Aug 11 15:15, Andy Koppe wrote:
> 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?
Weeeell, don't ask me! Actually, since the NT kernel doesn't have a
notion of a current working directory, the CWD is only used in the Win32
API anyway. And, come on, *nobody* ever needs a CWD path longer than
MAX_PATH, right?
> > 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.
Where is "somewhere safer"? I mean, even CMD.EXE uses it as fallback.
What about Cygwin's root dir?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat