Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cuae2!gatech!lll-lcc!pyramid!prls!mips!dce
From: dce@mips.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: \"special\" shells a security hole?
Message-ID: <177@quacky.mips.UUCP>
Date: Fri, 13-Feb-87 10:33:04 EST
Article-I.D.: quacky.177
Posted: Fri Feb 13 10:33:04 1987
Date-Received: Sat, 14-Feb-87 23:07:01 EST
References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP>
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 55

In article <3088@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes:
>>gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) (gwyn@brl.arpa, <5615@brl-smoke.ARPA>):
>> In article <3063@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes:
>> >Just include "SHELL=/bin/sh" near the beginning of the makefile.
>> The problem is, you HAVE to do this or you run the risk of having
>> the Makefile break.  "Make" has no business providing variable
>> semantics for Makefiles dependent on the user's environment.  I
>> suppose the original reason for this in Augmented Make was to
>> permit redefining CC for cross-compilation, etc. without having
>> to edit zillions of Makefiles.  Too bad SHELL is honored too.
>I disagree completely.  Adding "SHELL=/bin/sh" is an extremely trivial
>sacrifice to do compared to the flexibility it gives.  The Bourne shell
>is not, nor should ever be considered as, the be-all-and-end-all of all
>shells.  If I want to use Korn shell constructs in my Makefile, then
>there ought to be a general, clean way of doing it, such as
>"SHELL=/bin/ksh".  Putting "/bin/ksh -c <cmd>" on every command line in
>the Makefile is an ugly kludge.  If Joe User down the hall only knows
>how to write csh shell scripts and wants to do something more than just
>sequential command execution in a Makefile (such as loops), he doesn't
>have to learn how to use the Bourne shell to do so.

I don't disagree with being ABLE to use a different shell, but I disagree
with the method that was used to implement it.

As Doug says, it isn't right that I have to edit already-working makefiles
just because AT&T decides to allow the SHELL variable. Maybe you don't
have 300-400 makefiles to maintain (I'd bet that Doug has thousands), but
some of us do, and don't like the idea of having to change every one of
them just to make them work again (note the operative word is "again").

What I really dislike about this implementation is that it assumes that
the default should be whatever my SHELL variable is, as opposed to the
shell that the makefile is written for.

If SHELL is to be used by make, the only proper way to do it is to require
that it be set in the makefile, but that for backwards compatability (or is
it no longer desirable to satisfy customers) the default should be
/bin/sh.

The problem isn't that SHELL is used, but that it's imported from the
environment. There's nothing in the makefile syntax that says that the
line

	SHELL=program

is required. Yet, for all practical purposes, it is.

No one is asking anyone to give up any flexibility. All Doug and I wish
is that someone familiar with software development problems had actually
examined the situation before blindly implementing what has turned
out to be a bad solution.
-- 
			David Elliott

UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:  	408-720-1700