affected tools, just by redefining, say _PATH_DEFPATH like this:This is not correct. the NT paths are (combined with your above paths)
#ifdef _PATH_DEFPATH #undef _PATH_DEFPATH #define _PATH_DEFPATH "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem" #endif
which contains both, NT and 9x paths. We could perhaps even change /usr/include/paths.h to reflect this, at one point.
"/usr/bin:/bin:$SYSTEMROOT/system32:$SYSTEMROOT:$SYSTEMROOT/COMMAND:$SYSTEMROOT/system32/Wbem" (and actually a few more paths, with some variation by w32 version)
$SYSTEMROOT is NOT the same thing as C:\WINDOWS, even if that is what your system reports. OK, Cygwin has to escape/expand $SYSTEMROOT, because it is not good to have ":" in your Linux-like path names. I digress.
However, consider a system, where disk space is running low on the C: drive, so most data & programs are on the D:, or other drives. Or possibly centralized on a networked N: drive. This happens often to me, btw.
OK, now I'm going to get crazy with this scenario: Cygwin is on the D: drive. The SYSTEMROOT is on the E: drive. However the E: drive gets network remapped (can thin clients do this?) or is ASSIGNed or SUBSTed.
Now the problem is, SYSTEMROOT is set in the registry. How well is this registry key protected from crackers? And, in any case, if we do believe that c:\windows or /windows is in our PATH, how do we know that the directory has not been hijacked through a symlink, subst, shortcut or assign? OTOH, a cracker could try to modify your PATH setting script to "/cracker/bin:/usr/bin:/bin:..." Although, where ntfs is fully supported, you can limit permissions on the script file.
I hope this helps.
