Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!laidbak!daveb
From: daveb@i88.isc.com (Dave Burton)
Newsgroups: comp.lang.perl
Subject: Re: #! troubles
Summary: why not to have exec scan $PATH
Keywords: exec, kernel, environment
Message-ID: <1990Jan15.215617.9659@i88.isc.com>
Date: 15 Jan 90 21:56:17 GMT
References: <2047@uvaarpa.virginia.edu>
Sender: stevea@i88.isc.com (Steve Alexander)
Followup-To: comp.unix.questions
Organization: Interactive Systems nee Lachman Associates
Lines: 53

[ Followups redirected to comp.unix.questions ]

In article <2047@uvaarpa.virginia.edu> worley@compass.com writes:
>> Assuming the kernel gets your $PATH (which it doesn't, but pretend) -
>
> Well, exec() seems to be able to pass it to the new program, and
> exec() seems to be a kernel call...

(Pedantic: In 4.[23]bsd exec() is not a syscall, nor even a standard
C library call. See execve(2), execl(3) in the BSD manuals. In SVR3.x,
exec() _is_ a kernel routine and is in sysent, but the libraries don't
reference it and I'll be hanged if I know who uses it.)

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.

>> What happens when the PATH is ".:/bin:/usr/bin", and the
>> script is suid root? How about:
>
> Yes, of course, if you have a setuid script, you don't want to have
> the kernel search the path for the interpreter.  But setuid things are
> *always* a special case.  If you want to write setuid scripts, you
> have to have a trusted interpreter, and root has to install it in a
> safe place, and the script has to hard-code its location.  
>
> But in the ordinary case, it would make life much easier if
> interpreter paths didn't have to be hard-coded.

If you are not on a system supporting #!, this whole topic is moot since
the interpreter will not be invoked, no matter where it lives. The shell
will simply complain of syntax errors. (I think SVR3.2 csh attempts #! by
itself, so these csh users may disagree here.)

Otherwise:

If you are root, this point is moot, as you can scribble anywhere you please.
Put the interpreter in /usr/local/bin and leave the scripts alone.

If you are not root, then put the interpreter where you want/can, and change
the #! line to point to this location. The only time this comes into play is
with scripts received from a third party, since (presumably) locally written
scripts know where their interpreter lives. Third party scripts are handled
anyway (stripping off mail headers, for instance), so the additional effort
to change "#!/usr/local/bin/x" to, say, "#!/u/myname/bin/x" is trivial. This
is little justification to change the kernel.

If you're adamant, petition your UNIX vendor. (Don't expect much.)

> Dale Worley		Compass, Inc.			worley@compass.com
--
Dave Burton
uunet!ism780c!laidbak!daveb