At 02:26 PM 5/8/2004 -0400, Christopher Faylor wrote: >On Sat, May 08, 2004 at 02:12:16PM -0400, Pierre A. Humblet wrote: >>On Fri, 7 May 2004 22:55:29 -0400, Christopher Faylor wrote: >>>The memory leak is a good point (and has mildly bothered me since >>>implemented this) but aren't you essentially opening a mechanism to >>>access things outside of the chrooted environment with this patch? >> >>I don't think so. spawn uses path_conv::check, which will bomb if the >>program is outside the chroot area, no matter the Windows PATH. One >>has to be careful not to put any Windows program in that area, as it >>won't honor the changeroot. DLLs may open files outside of the chroot >>area, but that's independent of the DLLs locations. > >Ok.
Well, I decided to check what I wrote, and it's more complicated. It turns out that find_exec uses the Windows PATH (although there is a FIXME about that, in spawn_guts), and then it calls perhaps_suffix(), which uses path_conv::check. So there is no security problem. However because the PATH contains Win32 paths, the mount flags are not picked up. I also noticed something weird, running from a DOS shell: Compare C:\Home\Pierre>sh -c "env -u PATH echo yes" env: echo: No such file or directory and C:\Home\Pierre>env -u PATH echo yes yes find_exec finds the path in the second case! That has something to do with caching in the win_env. The Windows PATH is still set, perhaps because the program manipulates the environment directly or because unsetenv doesn't clear the cache. case 1: 15670 168943 [main] env 644047 find_exec: find_exec (true) 163 169106 [main] env 644047 getwinenv: can't set native for PATH= since no environ yet 155 169261 [main] env 644047 find_exec: = find_exec (true) case 2: 4116 37022 [main] env 49536259 find_exec: find_exec (true) 171 37193 [main] env 49536259 getwinenv: can't set native for PATH= since no environ yet 160 37353 [main] env 49536259 find_exec: PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;c:\progra~1\cygwin\bin Pierre
