[Patch]: Improving the anonymous ftp environment.
Pierre A. Humblet
Sun May 9 15:12:00 GMT 2004
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.
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:
C:\Home\Pierre>sh -c "env -u PATH echo yes"
env: echo: No such file or directory
C:\Home\Pierre>env -u PATH echo 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.
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)
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:
More information about the Cygwin-patches