execve("/bin/sh", 0, 0); in a pipe

Question

I have the following example program:

#include <stdio.h>

int
main(int argc, char ** argv){
    char buf[100];

    printf("Please enter your name: ");
    fflush(stdout);
    gets(buf);
    printf("Hello \"%s\"\n", buf);

    execve("/bin/sh", 0, 0);
}

I and when I run without any pipe it works as it should and returns a sh promt:

bash$ ./a.out
Please enter your name: warning: this program uses gets() which is unsafe.
testName
Hello "testName"
$ exit
bash$

But this does not work in a pipe, i think I know why that is, but I cannot figure out a solution. Example run bellow.

bash$ echo -e "testName\npwd" | ./a.out
Please enter your name: warning: this program uses gets() which is unsafe.
Hello "testName"
bash$

I figure this has something to do with the fact that gets empties stdin in such a way that /bin/sh receives a EOF and promtly quits without an error message.

But how do I get around this (without modifying the program, if possible, and not removing gets, if not) so that I get a promt even though I supply input through a pipe?

P.S. I am running this on a FreeBSD (4.8) machine D.S.

***NEVER*** use `gets`. It **always** opens a buffer overflow security hole. — ThiefMaster, Dec 14 '11 at 17:53
I know ;) ... this is part of a buffer overflow attempt on a computer at the security lab at my university. Purely academic. =D — A. Nilsson, Dec 14 '11 at 17:58

score 10 · Accepted Answer · answered Dec 14 '11 at 18:02

You can run your program without any modifications like this:

(echo -e 'testName\n'; cat ) | ./a.out

This way you ensure that your program's standard input doesn't end after what echo outputs. Instead, cat continues to supply input to your program. The source of that subsequent input is your terminal since this is where cat reads from.

Here's an example session:

bash-3.2$ cc stdin_shell.c 
bash-3.2$ (echo -e 'testName\n'; cat ) | ./a.out 
Please enter your name: warning: this program uses gets(), which is unsafe.
Hello "testName"
pwd
/home/user/stackoverflow/stdin_shell_question
ls -l
total 32
-rwxr-xr-x  1 user  group  9024 Dec 14 18:53 a.out
-rw-r--r--  1 user  group   216 Dec 14 18:52 stdin_shell.c
ps -p $$
  PID TTY           TIME CMD
93759 ttys000    0:00.01 (sh)
exit

bash-3.2$

Note that because shell's standard input is not connected to a terminal, sh thinks it is not executed interactively and hence does not display the prompt. You can type your commands normally, though.

Ah.. yes you are correct, (I actually managed to find this solution before a saw your post, but thank you for putting it up here). — A. Nilsson, Dec 14 '11 at 18:20

score 3 · Answer 2 · answered Dec 14 '11 at 18:02

3

Using execve("/bin/sh", 0, 0); is cruel and unusual punishment for the shell. It gives it no arguments or environment at all - not even its own program name, nor even such mandatory environment variables as PATH or HOME.

answered Dec 14 '11 at 18:02

Jonathan Leffler

730,956
141
904
1,278

2

well... yeah I agree completely, but this is simply used as an experiment. I would never use this in anything similar to a usable program. – A. Nilsson Dec 14 '11 at 18:09

score 1 · Answer 3 · answered Dec 14 '11 at 17:58

Not 100% sure of this (the precise shell being used and the OS might throw these answers a bit; I believe that FreeBSD uses GNU bash by default as /bin/sh?), but

sh may be detecting that its input is not a tty.

or

Your version of sh might go into non-interactive mode like that also if called as sh, expecting login will prepend a - onto argv[0] for it. Setting up execve ("/bin/sh", { "-sh", NULL}, NULL) might convince it that it's being run as a login shell.

execve("/bin/sh", 0, 0); in a pipe

3 Answers3

Linked