On Mar 15 12:32, Ilguiz Latypov wrote: > > > This has been changed deliberately, otherwise > > the execp functions have a potential security problem. If you omit the > > NNF flag, the function returns the original path unchanged, instead of > > NULL. > > I see that my conjecture about the root cause of the observed inconsistency > was incorrect. But my conjecture was only secondary to the patch. The > conjecture was about spawnvpe() succeeding where execvp() failed. Your > answer means that spawnvpe() should also call find_exec() with the extra 2 > parameters, "PATH=" and FE_NNF. > > Is my primary concern still valid? I.e., should execvp..()/spawnvp..() > succeed in executing backslash notation of relative and absolute paths? If > these inputs should be allowed, did my patch address the issue correctly? > > I agree that a basename-only path should not resolve against current > directory according to the execvp..() specs. I believe the relative and > absolute paths are allowed to resolve.
I checked this situation in cmd.exe, and it is not capable of using paths relativ to %Path%. In other words, if %Path% contains a path c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe, then calling "baz" works, but calling "bar\baz" fails. OTOH, the SearchPath function does it right. So, yes, maybe we should care for this situation but it's not something to worry about a lot. I'll look into it again at some point after 1.7.2 has been released. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
