Hi, Shachar.
You look at correct place and got everything right.
Almost. OK, everything you look kernel side is OK.
When you run program from the shell, shell use
not execve, but execvp (or execlp)
from the man execve
===========================================
Special semantics for execlp() and execvp()
The functions execlp() and execvp() will
duplicate the actions of the
shell in searching for an executable file if
the specified filename
does not contain a slash (/) character. The
search path is the path
specified in the environment by the PATH
variable. If this variable
isnt specified, the default path
:/bin:/usr/bin is used. In addi-
tion, certain errors are treated specially.
If permission is denied for a file (the
attempted execve(2) returned
EACCES), these functions will continue
searching the rest of the search
path. If no other file is found, however, they
will return with the
global variable errno set to EACCES.
--------> Below is important part
<------------------------
If the header of a file isnt recognized
(the attempted execve(2)
returned ENOEXEC), these functions will
execute the shell (/bin/sh)
with the path of the file as its first
argument. (If this attempt
fails, no further searching is done.)
===========================================
If you use compile program
#include <stdlib.h>
int main(int argc, char *argv[], char *envp[])
{
execve(argv[1], &argv[1], envp);
}
and run it under strace
strace program /tmp/file2
You'll see, that execve return ENOEXEC, as it should
(and as you saw in the kernel sources)
Regards,
Valery.
--- Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
> I tried the following experiment. /tmp/file1 (marked
> executable) has the
> following content:
>
> #!/bin/date
>
>
> echo "$@"
>
>
> /tmp/file2 has the following content:
>
> #!/tmp/file1
>
>
> echo "File2"
>
>
> when I run file2, I expect it to print out the
> current date. Instead, it
> prints out "File2". In other words, it goes to
> /bin/sh to execute.
>
>
> I tried going over the kernel code that handles
> this, but I must be
> looking at the wrong place. I got as far as the
> function "load_script"
> (fs/binfmt_script.c line 18 in the 2.6.23 kernel
> code), which seems to
> go over the file, extract the interpreter, and
> restart the entire
> process. Of course, once the process has restarted,
> bprm->sh_bang is not
> zero (line 25 of the file), and the function returns
> ENOEXEC. This
> explains why a shell script cannot be the
> interpreter for a shell script.
>
>
> What is not explained, however, is what does happen.
> I have not been
> able to locate what happens when the kernel runs out
> of functions that
> may make sense of the file we try to execute (aside
> from returning
> ENOEXEC, which does not seem to be what is actually
> happening). I have
> also been unable to locate where in the source there
> is any special
> casing of /bin/sh (aside from when the kernel cannot
> find /sbin/init,
> /etc/init and /bin/init during boot).
>
>
> What's going on here?
>
>
> Shachar
>
>
>
>
=================================================================
> To unsubscribe, send mail to
> [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g.,
> run the command
> echo unsubscribe | mail
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
