From owner-freebsd-bugs  Sat Sep 16 12: 0: 7 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8CF4237B43C
	for <freebsd-bugs@FreeBSD.org>; Sat, 16 Sep 2000 12:00:01 -0700 (PDT)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id MAA84153;
	Sat, 16 Sep 2000 12:00:01 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by hub.freebsd.org (Postfix) with ESMTP id 8B9C537B422
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 16 Sep 2000 11:50:10 -0700 (PDT)
Received: (from robert@localhost)
	by fledge.watson.org (8.9.3/8.9.3) id OAA03050;
	Sat, 16 Sep 2000 14:50:11 -0400 (EDT)
	(envelope-from robert)
Message-Id: <200009161850.OAA03050@fledge.watson.org>
Date: Sat, 16 Sep 2000 14:50:11 -0400 (EDT)
From: rwatson@freebsd.org
Reply-To: rwatson@freebsd.org
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: bin/21315: Bizarre shell interpreter failure mode
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         21315
>Category:       bin
>Synopsis:       Shells often behave oddly when executing shell scripts
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 16 12:00:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Robert Watson
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
>Environment:

FreeBSD mocking.southhadley.watson.org 4.1-STABLE FreeBSD 4.1-STABLE #1: Mon Aug  7 14:13:19 EDT 2000     root@numocking.gw.tislabs.com:/usr/src/sys/compile/MOCKING  i386

>Description:

Shells appear to behave oddly when executing shell scripts in a number of
situations.

(1) When the kernel discovers that the interpreter used is another
    interpreter, it generally returns ``Exec format error'' (ENOEXEC).
    However, when csh and sh find themselves in the same situation, they
    don't return that error, they execute the script using their own
    interpreter.

(2) When in single-user mode, the sh shell appears to assume that any
    script it runs should be executed using its own interpreter, not
    the interpreter at the top of the file.  In multi-user mode, this
    appears to work fine.

>How-To-Repeat:

(1)

    $ cat /tmp/test1
    #!/tmp/test2
    echo This is test1, meant to execute using test2
    $ cat /tmp/test2
    #!/tmp/test1
    echo This is test2, meant to execute with test1
    $ /tmp/test1
    This is test1, meant to execute using test2
    $ /tmp/test2
    This is test2, meant to execute with test1
    $

I.e., executing test1 resulted in sh executing it, instead of ENOEXEC.
Similarly with test2.  Neither resulted in a recursive call, which is
good.  This seems like a poor failure-mode -- it's inconsistent with
the kernel execve() implementation's failure mode, and it runs things
when you would hope that it wouldn't (always bad).

(2)

Boot to single user mode, select /bin/sh as the shell, and attempt to
execute a shell script relying on csh features.

>Fix:

Not attached.


>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message