bin/51207: /bin/sh ". /dev/tty" discards the first 4 characters of tty input

[kre%munnari.OZ.AU@localhost]

>Number:         51207
>Category:       bin
>Synopsis:       /bin/sh ". /dev/tty" discards the first 4 characters of tty input
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 01 04:55:00 +0000 2016
>Originator:     Robert Elz
>Release:        NetBSD 7 -->
>Organization:
>Environment:
System: NetBSD andromeda.noi.kre.to 7.99.26 NetBSD 7.99.26 (VBOX64-1.1-20160128) #43: Thu Jan 28 16:09:08 ICT 2016 kre%onyx.coe.psu.ac.th@localhost:/usr/obj/current/kernels/amd64/VBOX64 amd64
Architecture: x86_64
Machine: amd64
>Description:
	The test to avoid reading ELF binaries as shell scripts
	reads the first 4 characters to compare them with the ELF
	magic number - then rewinds the file so the data there can
	be read in the normal shell read path.   That fails on
	devices where lseek() is ignored (like ttys).   If the lseek()
	generates an error, the shell aborts reading the file (which
	is OK, such files are almost certainly not really shell input)
	but when the lseek() fails silently, the shell has lost the
	4 chars it read.

>How-To-Repeat:

	sh /dev/tty
	echo hello
	hello: not found

	The first 4 chars "echo" are dropped, leaving " hello" as the cmd.

	sh /dev/tty
	    echo hello
	hello
	^D

	The four spaces (which can be anything except the ELF magic number)
	are dropped, then all works OK.

	or in an older shell, do ...

	/bin/sh -c '. /dev/tty'
	echo hello
	hello: not found

	/bin/sh -c '. /dev/tty'
	    echo hello
	hello
	^D

>Fix:
	An elaborate pushback smethod could be used to return the lost data
	to the shell input stream (it already has the mechanism) but
	it is easier to just only test for ELF on regular files, not
	on devices, piper, etc (if someone uses a named pipe as input
	and that pipe contains an ELF binary, then let them suffer!)

	So that is what will be done soon.

	The '.' version of the problem does not currently exist in the
	NetBSD current shell, as . of non-regular files is currently
	prohibited.   But that is about to be fixed, and that instance
	of the bug would have reappeared (it was testing the change to
	allow . on other kinds of files that uncovered this.)