This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: /WINDOWS
This allows to keep the above described code to set $PATH in the
affected tools, just by redefining, say _PATH_DEFPATH like this:
#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.
This is not correct. the NT paths are (combined with your above paths)
"/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.