Mon Dec 8 15:17:00 GMT 2003
This allows to keep the above described code to set $PATH in the
>affected tools, just by redefining, say _PATH_DEFPATH like this:
>#define _PATH_DEFPATH "/usr/bin:/bin:/WINDOWS/system32:/WINDOWS:/WINDOWS/COMMAND/WINDOWS/system32/Wbem"
>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)
(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
Although, where ntfs is fully supported, you can limit permissions on the script file.
I hope this helps.
More information about the Cygwin-apps