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 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


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