#! troubles

[Dave Burton]

In article <7661 at quick.COM> srg at quick.COM (Spencer Garrett) writes:
|In article <1990Jan15.215617.9659 at i88.isc.com>, daveb at 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