srg@quick.COM (Spencer Garrett) (01/17/90)
In article <1990Jan15.215617.9659@i88.isc.com>, daveb@i88.isc.com (Dave Burton) writes: > In article <2047@uvaarpa.virginia.edu> worley@compass.com writes: > >> Assuming the kernel gets your $PATH (which it doesn't, but pretend) - > > > The kernel does not get _any_ environment variables. Sure, it passes an > environment pointer to the exec'd process, but this does not imply the > environment is scanned. That would be _very_ expensive. Au contraire. The environment strings are *copied* to the child process in the same manner as the argv strings. The kernel could easily scan for a PATH variable. The main argument against this is that it's the sort of feeping creaturism for which Berkeley has been long and loudly chastized, though given that #! interpretation got moved in I don't see this as an inappropriate adjunct. I think it got left out mostly because coding this sort of thing at the kernel level is a mess.
daveb@i88.isc.com (Dave Burton) (01/18/90)
In article <7661@quick.COM> srg@quick.COM (Spencer Garrett) writes: |In article <1990Jan15.215617.9659@i88.isc.com>, daveb@i88.isc.com (Dave Burton) writes: |> >> Assuming the kernel gets your $PATH (which it doesn't, but pretend) - |> The kernel does not get _any_ environment variables. Sure, it passes an |> environment pointer to the exec'd process, but this does not imply the |> environment is scanned. That would be _very_ expensive. | |Au contraire. The environment strings are *copied* to the child process |in the same manner as the argv strings. The kernel could easily scan |for a PATH variable. The main argument against this is that it's the |sort of feeping creaturism for which Berkeley has been long and loudly |chastized, though given that #! interpretation got moved in I don't |see this as an inappropriate adjunct. I think it got left out mostly |because coding this sort of thing at the kernel level is a mess. Unfortunately, I caught my gaff after I posted. Yes, of course the environment is copied (where would the pointer point? Oops.) I suppose I don't see this as feeping creaturism so much as simply wrong: . The kernel does not examine (better than the word get :-) any environment variables, for any case. IMHO, it shouldn't. The kernel should not change its behavior due to user environment changes. . exec[lv]p(3) were written to do $PATH scanning on exec's. At this time there was the opportunity to add $PATH scanning to the kernel, but it wasn't done, which suggests that the proper place to do this is uspace. Making exec[lv]p(3) equivalent to exec[lv](3) and placing $PATH scanning in the kernel today would break other programs (e.g. execl("prog","prog",0) with $PATH not containing the current directory). Therefore, this would have to be a special case for #! execution. . This creature is even more special case: given an suid/sgid script, $PATH scanning cannot be trusted - trivially easy to spoof. Thus, $PATH scanning wouldn't always work. The Principle of Least Astonishment? . The kernel contortions required to support this would be messy, at best (good argument for not changing the kernel, huh?). . Aside from kernel issues: as stated later in the referenced article (in comp.lang.perl), there's no good reason to do this anyway. It helps nobody. I believe this is the strongest argument against it. -- Dave Burton uunet!ism780c!laidbak!daveb