m5d@bobkat.UUCP (Mike McNally ) (01/21/87)
My 4.2BSD documentation for execl(3) describes a "bug" involving failed
attempts to execute the shell to run a supposed command file.
According to the "man" page,
If execvp is called to execute a file that turns out to be a
shell command file, and if it is impossible to execute the
shell, the values of argv[0] and argv[-1] will be modified
before return.
This seemed very strange to me. Which "argv"? Why does it mess with
argv[-1]??
I wrote a fake version of execve(2) which prints the address of the
argument list passed to it, then sets "errno" to ENOEXEC and returns.
This fools execvp, which then tries to run the shell. The argument
list passed the second time is somewhere on the stack; it isn't my
original "argv" at all.
In short I can't cause this "bug" to manifest itself; does it really
exist?
--
**** ****
**** At Digital Lynx, we're almost in Garland, but not quite ****
**** ****
Mike McNally Digital Lynx Inc.
Software (not hardware) Person Dallas TX 75243
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474guy%gorodish@Sun.COM (Guy Harris) (01/23/87)
> According to the ("exec") "man" page, > > If execvp is called to execute a file that turns out to be a > shell command file, and if it is impossible to execute the > shell, the values of argv[0] and argv[-1] will be modified > before return. > > This seemed very strange to me. Which "argv"? Why does it mess with > argv[-1]?? > ... > In short I can't cause this "bug" to manifest itself; does it really > exist? Nope. This same claim is in the V7 manual page. It may have been true back then; I don't have V7 source handy to check. The 4.2BSD and S5 code do the same thing if the file is a shell script. They build a new argument list, whose first entry is "sh", whose second entry is the name of the file that it found, and whose subsequent entries are the 1st through Nth arguments (i.e., argv[1] through argv[argc-1]). My pure guess is that if this bug ever existed, it was because some version of "execvp" *didn't* make a copy of the argument list, but just smashed argv[0] with the name of the file and argv[-1] with "sh" and fed this somewhat spurious argument list to "execv". Needless to say, smashing argv[-1] is violently anti-social, since it's probably some random piece of user data. Given that the 4.2BSD and S5 code are basically the same, I suspect that the fix was in some version of UNIX from Research that predates both of them. A likely candidate for this version would be V7; it may be that the documentation, as usual, trailed the code.