Message-Id:	<199810190939.LAA34738@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Mon, 19 Oct 1998 11:44:54 +0300
MIME-Version:	1.0
Subject:	Re: Patch for src/libc/dos/process/dosexec.c
CC:	djgpp-workers AT delorie DOT com, dj AT delorie DOT com
References:	<Pine DOT A32 DOT 3 DOT 91 DOT 981017152040 DOT 83628A-100000 AT ieva01 DOT lanet DOT lv>
In-reply-to:	<Pine.SUN.3.91.981018135225.2705l-100000@is>
X-mailer:	Pegasus Mail for Win32 (v3.01b)
Reply-To:	djgpp-workers AT delorie DOT com

Date sent:      	Sun, 18 Oct 1998 13:52:44 +0200 (IST)
From:           	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject:        	Re: Patch for src/libc/dos/process/dosexec.c

> 
> On Sat, 17 Oct 1998, Andris Pavenis wrote:
> 
> > 	we should SKIP additional extension when it is "" to
> > 	avoid BAT file (or some script) missinterpretted as
> > 	unstubbed COFF.
> 
> Thanks for the patch.
> 
> However, I'm not sure this is the right thing to do to correct the
> bug.  This patch loses when foo.bat *is* an unstubified COFF image
> (or, in fact, anything other than a batch file).  Preventing users
> from being able to have a file with a .bat extension that isn't a
> batch file is a subtle restriction that shouldn't be introduced with
> no good reason, IMHO.
> 
> I think a better way to correct this bug would be to change go32_exec
> function (which gets called by the original version of dosexec.c for
> this case) so that a file that is neither a V2 executable, nor a shell
> script, and doesn't have the DOS MZ signature (use the
> _V2_EXEC_FORMAT_EXE macro with the value returned by _check_v2_prog),
> is passed to __dosexec_command_exec (instead of direct_exec in the
> original code).  This is analogous to the handling of .sh, .pl, .sed
> etc. files, so why make a special treatment for a .bat file?
> 
> Andris, could you please try this alternative solution and see if it
> works?
> 

I think that calling unstubified COFF image as .BAT is at least 
slightly weird and confusing. Think about trying to run it by error 
from from COMMAND.COM, however I can imagine even worse 
things, for example, unstubified COFF image in disguise with 
extension .COM or .EXE (the same as doesn't have
'MZ' at start of file). 

It also means that all other previous detection is useless as all files 
will be executed will be executed using go32_exec() when LFN 
support is being used (adding extension "" matches all files). 
Therefore I'ts better to forbid to have unstubified COFF image in 
disguise with such extensions as .BAT, .COM, .EXE or something 
like.

Therefore I suggest using my previous patch. I also tried patching
go32_exec() and it worked, but as I said I would prefer not to do so.
I can send the patch if it is really needed.
 
One more note. Perhaps also extension "." should be added 
to array interpreters as valid for unstubified COFF.

Andris

- Raw text -