execve for script don't return ENOEXEC, bug ?

execve for script don't return ENOEXEC, bug ?

[Valery Reznic]

Hi,

I Have following to scripts:

a.sh
#!/bin/sh
echo "It's a.sh

and b.sh:
#! ./b.sh
echo "It's b.sh"

As per execve man page, script interpreter should not be script itself.
When I run it on my Fedora 8 x86_64 box (with stock kernel, never updated)
under strace I got following:

strace -f -e execve  setarch x86_64  ./b.sh 
execve("/usr/bin/setarch", ["setarch", "x86_64", "./b.sh"], [/* 23 vars */]) = 0
execve("./b.sh", ["./b.sh"], [/* 23 vars */]) = -1 ENOEXEC (Exec format error)
execve("/bin/sh", ["/bin/sh", "./b.sh"], [/* 23 vars */]) = 0
It's b.sh

I.e execve failed as it should

When I run same scripts on Fedora 12 x86_64 box with stock kernel 2.6.31.5-127.fc12.x86_64 I got following:

strace -f -e execve setarch i386  ./b.sh 
execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 41 vars */]) = 0
execve("./b.sh", ["./b.sh"], [/* 41 vars */]) = 0
It's a.sh

I.e execve succeeded, instead of failing with ENOEXEC

Regards,
Valery.

P.S. I am not subscribed to this list, so please CC me






      

Re: execve for script don't return ENOEXEC, bug ?

[Andrew Morton]

On Thu, 11 Mar 2010 02:56:16 -0800 (PST)
Valery Reznic <valery_reznic@yahoo.com> wrote:

> Hi,
> 
> I Have following to scripts:
> 
> a.sh
> #!/bin/sh
> echo "It's a.sh
> 
> and b.sh:
> #! ./b.sh
> echo "It's b.sh"
> 
> As per execve man page, script interpreter should not be script itself.
> When I run it on my Fedora 8 x86_64 box (with stock kernel, never updated)
> under strace I got following:
> 
> strace -f -e execve  setarch x86_64  ./b.sh 
> execve("/usr/bin/setarch", ["setarch", "x86_64", "./b.sh"], [/* 23 vars */]) = 0
> execve("./b.sh", ["./b.sh"], [/* 23 vars */]) = -1 ENOEXEC (Exec format error)
> execve("/bin/sh", ["/bin/sh", "./b.sh"], [/* 23 vars */]) = 0
> It's b.sh
> 
> I.e execve failed as it should
> 
> When I run same scripts on Fedora 12 x86_64 box with stock kernel 2.6.31.5-127.fc12.x86_64 I got following:
> 
> strace -f -e execve setarch i386  ./b.sh 
> execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 41 vars */]) = 0
> execve("./b.sh", ["./b.sh"], [/* 41 vars */]) = 0
> It's a.sh
> 
> I.e execve succeeded, instead of failing with ENOEXEC
> 

It works for me, I think:

z:/home/akpm> uname -a
Linux z 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
z:/home/akpm> cat b.sh
#! ./b.sh
echo "It's b.sh"
z:/home/akpm> strace -f -e execve setarch i386  ./b.sh 
execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 60 vars */]) = 0
execve("./b.sh", ["./b.sh"], [/* 60 vars */]) = -1 ENOEXEC (Exec format error)
execve("/bin/sh", ["/bin/sh", "./b.sh"], [/* 60 vars */]) = 0
It's b.sh


Did I do something wrong?  If not, I wonder what's different.

Re: execve for script don't return ENOEXEC, bug ?

[David Newall]

On Thu, 11 Mar 2010 02:56:16 -0800 (PST) Valery Reznic 
<valery_reznic@yahoo.com> wrote:
> Hi,
>
> I Have following to scripts:
>
> a.sh
> #!/bin/sh
> echo "It's a.sh
>
> and b.sh:
> #! ./b.sh
> echo "It's b.sh"
>   
[...]
> When I run same scripts on Fedora 12 x86_64 box with stock kernel 2.6.31.5-127.fc12.x86_64 I got following:
>
> strace -f -e execve setarch i386  ./b.sh 
> execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 41 vars */]) = 0
> execve("./b.sh", ["./b.sh"], [/* 41 vars */]) = 0
> It's a.sh

I see no circumstance which would make b.sh invoke a.sh (and thus emit 
"It's a.sh"). Are you sure these are the actual scripts and output?

On the other hand, if the output was "It's b.sh", this is compatible 
with many historical versions of UNIX, which assumed /bin/sh to be the 
script interpreter. On
2.6.28-16-generic #55-Ubuntu SMP i686 GNU/Linux I get successful output 
for the following variants of "x.sh":

:
echo worked

and

#!
echo worked

and

#! ./x.sh
echo worked

Re: execve for script don't return ENOEXEC, bug ?

[Valery Reznic]

--- On Sat, 3/20/10, David Newall <davidn@davidnewall.com> wrote:

> From: David Newall <davidn@davidnewall.com>
> Subject: Re: execve for script don't return ENOEXEC, bug ?
> To: "Valery Reznic" <valery_reznic@yahoo.com>
> Cc: linux-kernel@vger.kernel.org
> Date: Saturday, March 20, 2010, 2:37 AM
> On Thu, 11 Mar 2010 02:56:16 -0800
> (PST) Valery Reznic <valery_reznic@yahoo.com>
> wrote:
> > Hi,
> > 
> > I Have following to scripts:
> > 
> > a.sh
> > #!/bin/sh
> > echo "It's a.sh
> > 
> > and b.sh:
> > #! ./b.sh
> > echo "It's b.sh"
> >   
> [...]
> > When I run same scripts on Fedora 12 x86_64 box with
> stock kernel 2.6.31.5-127.fc12.x86_64 I got following:
> > 
> > strace -f -e execve setarch i386  ./b.sh
> execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"],
> [/* 41 vars */]) = 0
> > execve("./b.sh", ["./b.sh"], [/* 41 vars */]) = 0
> > It's a.sh
> 
> I see no circumstance which would make b.sh invoke a.sh
> (and thus emit "It's a.sh"). Are you sure these are the
> actual scripts and output?

Of course you are right. Somehow I messed up b.sh
(OK, this file is so long and complicated, so no wonder :)
Anyway my bad, sorry.

In the b.sh interpreter should be ./a.sh

Another attempt to provide correct data:

[valery@localhost ~]$ cat a.sh 
#!/bin/sh
echo "It's a.sh"
[valery@localhost ~]$ cat b.sh 
#! ./a.sh
echo "It's b.sh"
[valery@localhost ~]$ 
[valery@localhost ~]$ strace -f -e execve setarch i386 ./b.sh 
execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 40 vars */]) = 0
execve("./b.sh", ["./b.sh"], [/* 40 vars */]) = 0
It's a.sh
[valery@localhost ~]$ 




> 
> On the other hand, if the output was "It's b.sh", this is
> compatible with many historical versions of UNIX, which
> assumed /bin/sh to be the script interpreter. On
> 2.6.28-16-generic #55-Ubuntu SMP i686 GNU/Linux I get
> successful output for the following variants of "x.sh":
> 
> :
> echo worked
> 
> and
> 
> #!
> echo worked
> 
> and
> 
> #! ./x.sh
> echo worked
My problem is not incorrect output, but successful execve, when script's interpreter is interpreter itself.

Somewhere between Fedora 8 and Fedora 12 execve's behaviour changed.

@Andrew:
When b.sh has interpreter ./b.sh I got expected ENOEXEC, same as you.

Regards,
Valery.

> 


      

Re: execve for script don't return ENOEXEC, bug ?

[David Newall]

Valery Reznic wrote:
> [valery@localhost ~]$ cat a.sh 
> #!/bin/sh
> echo "It's a.sh"
> [valery@localhost ~]$ cat b.sh 
> #! ./a.sh
> echo "It's b.sh"
> [valery@localhost ~]$ 
> [valery@localhost ~]$ strace -f -e execve setarch i386 ./b.sh 
> execve("/usr/bin/setarch", ["setarch", "i386", "./b.sh"], [/* 40 vars */]) = 0
> execve("./b.sh", ["./b.sh"], [/* 40 vars */]) = 0
> It's a.sh
>   

That is the correct output for a script which is being interpreted by 
a.sh, when a.sh prints "It's a.sh" using /bin/sh as its interpreter.  
Remember, you didn't ask /bin/sh to interpret b.sh, you asked a.sh to do 
it, and a.sh is a simple echo statement, not an interpreter.  There is 
no error here.

Re: execve for script don't return ENOEXEC, bug ?

[Valery Reznic]

--- On Sat, 3/20/10, David Newall <davidn@davidnewall.com> wrote:

> From: David Newall <davidn@davidnewall.com>
> Subject: Re: execve for script don't return ENOEXEC, bug ?
> To: "Valery Reznic" <valery_reznic@yahoo.com>
> Cc: linux-kernel@vger.kernel.org
> Date: Saturday, March 20, 2010, 11:41 AM
> Valery Reznic wrote:
> > [valery@localhost ~]$ cat a.sh #!/bin/sh
> > echo "It's a.sh"
> > [valery@localhost ~]$ cat b.sh #! ./a.sh
> > echo "It's b.sh"
> > [valery@localhost ~]$ [valery@localhost ~]$ strace -f
> -e execve setarch i386 ./b.sh execve("/usr/bin/setarch",
> ["setarch", "i386", "./b.sh"], [/* 40 vars */]) = 0
> > execve("./b.sh", ["./b.sh"], [/* 40 vars */]) = 0
> > It's a.sh
> >   
> 
> That is the correct output for a script which is being
> interpreted by a.sh, when a.sh prints "It's a.sh" using
> /bin/sh as its interpreter.  Remember, you didn't ask
> /bin/sh to interpret b.sh, you asked a.sh to do it, and a.sh
> is a simple echo statement, not an interpreter.  There
> is no error here.

execve's man page state that script's interprtert should not be 
interpreter itself:
------------------------------------------------------
   Interpreter scripts
       An  interpreter  script  is  a  text  file  that has execute permission
       enabled and whose first line is of the form:

           #! interpreter [optional-arg]

       The interpreter must be a valid pathname for an executable which is not
       itself  a  script. 
------------------------------------------------------

I.e, execve should return ENOEXEC. And it did it at least in Fedora 8 and earlier.

To me it looks like  execve and it's man page disagree. Do you know is it new intended behaviour of execve and just man page wasn't update or it's a bug in execve ?

Valery.
> 


      

Re: execve for script don't return ENOEXEC, bug ?

[David Newall]

Valery Reznic wrote:
> execve's man page state that script's interprtert should not be 
> interpreter itself:
> ------------------------------------------------------
>    Interpreter scripts
>        An  interpreter  script  is  a  text  file  that has execute permission
>        enabled and whose first line is of the form:
>
>            #! interpreter [optional-arg]
>
>        The interpreter must be a valid pathname for an executable which is not
>        itself  a  script. 
> ------------------------------------------------------
>
> I.e, execve should return ENOEXEC. And it did it at least in Fedora 8 and earlier.
>
> To me it looks like  execve and it's man page disagree. Do you know is it new intended behaviour of execve and just man page wasn't update or it's a bug in execve ?

Code and man pages do sometimes disagree.  I shan't address what the 
correct behaviour is, because if you ask three people you're sure to get 
four different answers, rather let's discuss what is desirable.  Without 
looking at how it works, we observe that a.sh can be executed without 
error.  If a.out were written in C it would qualify as an acceptable 
interpreter according to the man page, so why should it not qualify if 
it is interpreted?  I think it's desirable that it does qualify.  There 
could be sound reasons why only one level of interpreter can be 
invoked.  Perhaps loading a script interpreter is done as an exception 
in exec, and it's too ugly to allow recursive exceptions.  That would be 
a fair reason.  But if there's no reason, then don't have the 
restriction*.  Linux now apparently does permit interpreted 
interpreters, and I say that is the desirable result.

*Newall's second rule of programming: A program should impose no 
unnecessary restriction on its user.

Re: execve for script don't return ENOEXEC, bug ?

[Valery Reznic]

--- On Sat, 3/20/10, David Newall <davidn@davidnewall.com> wrote:

> From: David Newall <davidn@davidnewall.com>
> Subject: Re: execve for script don't return ENOEXEC, bug ?
> To: "Valery Reznic" <valery_reznic@yahoo.com>
> Cc: linux-kernel@vger.kernel.org
> Date: Saturday, March 20, 2010, 7:57 PM
> Valery Reznic wrote:
> > execve's man page state that script's interprtert
> should not be interpreter itself:
> >
> ------------------------------------------------------
> >    Interpreter scripts
> >        An  interpreter 
> script  is  a  text  file  that has
> execute permission
> >        enabled and whose first
> line is of the form:
> > 
> >            #!
> interpreter [optional-arg]
> > 
> >        The interpreter must be a
> valid pathname for an executable which is not
> >        itself  a 
> script.
> ------------------------------------------------------
> > 
> > I.e, execve should return ENOEXEC. And it did it at
> least in Fedora 8 and earlier.
> > 
> > To me it looks like  execve and it's man page
> disagree. Do you know is it new intended behaviour of execve
> and just man page wasn't update or it's a bug in execve ?
> 
> Code and man pages do sometimes disagree.  I shan't
> address what the correct behaviour is, because if you ask
> three people you're sure to get four different answers,
> rather let's discuss what is desirable.  Without
> looking at how it works, we observe that a.sh can be
> executed without error.  If a.out were written in C it
> would qualify as an acceptable interpreter according to the
> man page, so why should it not qualify if it is
> interpreted?  I think it's desirable that it does
> qualify.  There could be sound reasons why only one
> level of interpreter can be invoked.  Perhaps loading a
> script interpreter is done as an exception in exec, and it's
> too ugly to allow recursive exceptions.  That would be
> a fair reason.  But if there's no reason, then don't
> have the restriction*.  Linux now apparently does
> permit interpreted interpreters, and I say that is the
> desirable result.
For some reason I tough that ENOEXEC for 'interpreted interpreter' is posix requirement. But after closer look it appear to be only arbitrary restriction now lifted in Linux.

I had a look at the source http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/binfmt_misc.c
and it's obvious that 'interpreted interpreter' is intentional (and recursion depth is 4).
So, execve is behave as it should and only man page is lag behind.
Thank you for you help/


Just curios - who use this feature in the real world and what for ?

Valery.
> 
> *Newall's second rule of programming: A program should
> impose no unnecessary restriction on its user.
> 


      

Re: execve for script don't return ENOEXEC, bug ?

[Johannes Stezenbach]

(Cc: man page maintainer)

On Sun, Mar 21, 2010 at 01:33:28AM -0700, Valery Reznic wrote:
> --- On Sat, 3/20/10, David Newall <davidn@davidnewall.com> wrote:
> > Valery Reznic wrote:
> > > execve's man page state that script's interprtert
> > > should not be interpreter itself:
...
> > > To me it looks like  execve and it's man page
> > > disagree. Do you know is it new intended behaviour of execve
> > > and just man page wasn't update or it's a bug in execve ?
> > 
> > Code and man pages do sometimes disagree.  I shan't
> > address what the correct behaviour is, because if you ask
> > three people you're sure to get four different answers,
> > rather let's discuss what is desirable.  Without
> > looking at how it works, we observe that a.sh can be
> > executed without error.  If a.out were written in C it
> > would qualify as an acceptable interpreter according to the
> > man page, so why should it not qualify if it is
> > interpreted?  I think it's desirable that it does
> > qualify.  There could be sound reasons why only one
> > level of interpreter can be invoked.  Perhaps loading a
> > script interpreter is done as an exception in exec, and it's
> > too ugly to allow recursive exceptions.  That would be
> > a fair reason.  But if there's no reason, then don't
> > have the restriction*.  Linux now apparently does
> > permit interpreted interpreters, and I say that is the
> > desirable result.
> For some reason I tough that ENOEXEC for 'interpreted interpreter' is posix
> requirement. But after closer look it appear to be only arbitrary restriction
> now lifted in Linux.
> 
> I had a look at the source http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/binfmt_misc.c
> and it's obvious that 'interpreted interpreter' is intentional (and recursion depth is 4).
> So, execve is behave as it should and only man page is lag behind.
> Thank you for you help/
> 
> 
> Just curios - who use this feature in the real world and what for ?

It seems to have been changed in commit bf2a9a39639b8b51377905397a5005f444e9a892.
Maybe you could ask the author for details.


Johannes

Re: execve for script don't return ENOEXEC, bug ?

[Johannes Stezenbach]

(Cc: man page maintainer)

On Sun, Mar 21, 2010 at 01:33:28AM -0700, Valery Reznic wrote:
> --- On Sat, 3/20/10, David Newall <davidn-KzQzY1MbaKjAHznzqCTclw@public.gmane.org> wrote:
> > Valery Reznic wrote:
> > > execve's man page state that script's interprtert
> > > should not be interpreter itself:
...
> > > To me it looks like  execve and it's man page
> > > disagree. Do you know is it new intended behaviour of execve
> > > and just man page wasn't update or it's a bug in execve ?
> > 
> > Code and man pages do sometimes disagree.  I shan't
> > address what the correct behaviour is, because if you ask
> > three people you're sure to get four different answers,
> > rather let's discuss what is desirable.  Without
> > looking at how it works, we observe that a.sh can be
> > executed without error.  If a.out were written in C it
> > would qualify as an acceptable interpreter according to the
> > man page, so why should it not qualify if it is
> > interpreted?  I think it's desirable that it does
> > qualify.  There could be sound reasons why only one
> > level of interpreter can be invoked.  Perhaps loading a
> > script interpreter is done as an exception in exec, and it's
> > too ugly to allow recursive exceptions.  That would be
> > a fair reason.  But if there's no reason, then don't
> > have the restriction*.  Linux now apparently does
> > permit interpreted interpreters, and I say that is the
> > desirable result.
> For some reason I tough that ENOEXEC for 'interpreted interpreter' is posix
> requirement. But after closer look it appear to be only arbitrary restriction
> now lifted in Linux.
> 
> I had a look at the source http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/binfmt_misc.c
> and it's obvious that 'interpreted interpreter' is intentional (and recursion depth is 4).
> So, execve is behave as it should and only man page is lag behind.
> Thank you for you help/
> 
> 
> Just curios - who use this feature in the real world and what for ?

It seems to have been changed in commit bf2a9a39639b8b51377905397a5005f444e9a892.
Maybe you could ask the author for details.


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html