[comp.os.minix] executable scripts?, and retraction of bovine exhaust

root@agate.berkeley.edu (Charlie Root) (05/03/91)

In article <10120@plains.NoDak.edu> overby@plains.NoDak.edu (Glen Overby) writes (in part):
>I disagree.  The shell should not be looking at executables; it should
>merely "exec" them and the kernel should determine what is REALLY done with
>the executable, be it loaded as a binary image or fed through an interpreter.
>
>By requiring the "shell" to check for executable scripts, you complicate any
>program which chooses to use exec(2) since it, too, must open the executable
>and check for an interpreter.  Any executable should be "exec"-able.

I see a third alternative.  You could hack exec in the run-time
library to do the check.  This avoids the above objection, that any
program should be able to exec executables, since I presume most
programs call the RTL exec when they want to exec something.  (One
that didn't would make a great entry in the IOCCC though...)  And
putting the change in the RTL follows the grand principle of moving
policy to the highest convenient location.

Just a suggestion.

And on a separate topic, my recent diatribe here about the evils of
software patents contained one item that is apparently misinformation,
i.e. bullshit.  Among the ludicrous patents I listed was a patent on
the include file.  I got a message asking for more info on this, and
after some effort I find that I still have no info on it, leading me
to conclude that there is no such patent.  I regret having propagated
this rumor.  However, the other ludicrous patents I listed and the
dangers of this system are very real.  I urge all of you to read the
LPF position papers, which can be obtained by anonymous FTP from
prep.ai.mit.edu:/pub/lpf, or I will mail a copy on request.  And I
urge those of you in the US to consider joining the LPF, which is
engaging in lobbying efforts to eliminate software patents and
look-and-feel copyrights in the US.

Dave Cottingham			| "The low-bid contractor is not always
dc@caveat.berkeley.edu		|  the truly socially conscious one."
				| - Loni Hancock, mayor of Berkeley

wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (05/04/91)

Glen Overby wrote
>I disagree.  The shell should not be looking at executables; it should
>merely "exec" them and the kernel should determine what is REALLY done with
>the executable, be it loaded as a binary image or fed through an interpreter.
>
>By requiring the "shell" to check for executable scripts, you complicate any
>program which chooses to use exec(2) since it, too, must open the executable
>and check for an interpreter.  Any executable should be "exec"-able.

	What is an "executable"?  In the days before "#!" was in the
Berkeley kernel, the shell first tried to do an exec() and if this failed it
assummed that the file was in fact a shell script.  Having the shell look at
the first line of the file before assuming it is script for your particular
shell would not slow down the exec() (it's already failed) and really
wouldn't slow down interpreting of scripts much either since you have to
open and read them anyway.  If you later added support for "#!" to your
kernel, it would speed up the interpretation of such scripts slightly, but
wouldn't effect their functionality at all.  I'm not saying don't add this
to the kernel, but adding the code to the shell would provide much of the
functionality for most people.

				Bill Bogstad

Caveat:  Their would be one major difference between shell based and kernel
based handling of "#!".  If it is in the kernel, you can have setuid
scripts.  Such scripts are now frowned upon by many people as it is very
difficult to make standard shell scripts truly secure against crackers.
Some intepreters (like perl?) though can apparently handle this properly.

gpvos@cs.vu.nl (Gerben 'P' Vos) (05/06/91)

wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu writes:

>Caveat:  Their would be one major difference between shell based and kernel
>based handling of "#!".  If it is in the kernel, you can have setuid
>scripts.  Such scripts are now frowned upon by many people as it is very
>difficult to make standard shell scripts truly secure against crackers.
>Some intepreters (like perl?) though can apparently handle this properly.

No, but perl warns you and refuses to execute the script if you haven't
disabled setuid #! scripts in the (BSD) kernel. How it can check for that is
beyond my understanding (maybe it's in the configure script?).

. . . . . . . . . . . . . . . . . . . . . . . . . . . G e r b e n   V o s   <><
Aconet: BIGBEN!Gerben Vos  Internet: gpvos@cs.vu.nl
R.I.P. Radio Canada International   1942-1991