Newsgroups: comp.unix.wizards
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lethe!tvcent!comspec!scocan!john
From: john@sco.COM (John R. MacMillan)
Subject: Re: file attributes
Organization: SCO Canada, Inc.
Date: Tue, 25 Jun 1991 19:27:43 GMT
Message-ID: <1991Jun25.192743.8968@sco.COM>
References: <1991Jun20.021749.12011@gpu.utcs.utoronto.ca> <1991Jun21.191521.12644@sco.COM> <8509@auspex.auspex.com>
Sender: news@sco.COM (News administration)

|However, depending on what meaning (if any) you'd assign to "bloat",
|"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60
|lines to "kern_exec.c" in 4.3BSD, for example.

Like you, I'm not a fan of the term ``bloat''.  My reason for
mentioning #! was that I felt it belonged in user code, not because
it's big, but because there's no particularly good reason to put it in
the kernel.

|Presumably, your user-mode version would be done in the "execve()"
|library routine - i.e., instead of just being a wrapper around the
|"execve()" trap, as it is in most existing UNIX implementations, it'd
|check for ENOEXEC and, if that was the error, it'd check for a "#!"
|line, shuffle the argument list, and invoke the program specified by the
|"#!" line?

Actually, if I were about to change the semantics of a prominent UNIX
call, I would probably have given it a new name, but it's a little
late for that (not meaning to signal, I mean single, out the exec
calls :-) ).  Now that the use is widespread, I would do it the way you
suggest.  You could also get rid of the ugly hard-coded limits that
are in kern_exec.c; after all, dynamic sizing is easier in user code.

|(That'd lose the set-UID/set-GID capability, but it's not
|clear whether that's really a loss or not - even if you fix the known
|bugs with the set-UID shell script mechanism, would *you* trust some
|arbitrary shell, or the "awk"/"perl"/whatever interpreter, and the
|language it implements sufficiently that you'd want to write set-UID
|scripts in that language?)

I don't consider it a loss.  If you really REALLY need setuid scripts,
that too can be done without kernel support (ksh has an suid_exec
program to do this).  This has the added advantage that it gives the
sysadmin control over setuid scripts.

Just to be safe, I should say that I (obviously) do not claim to
represent my employer's views.