execve for script don't return ENOEXEC, bug ?
in [Kernel]
|
Prev: ST SPEAr: Added source files for SPEAr3xx machine family
Next: davinci: MMC: Pass number of SG segments as platform data
From: Valery Reznic on 20 Mar 2010 09:00 --- On Sat, 3/20/10, David Newall <davidn(a)davidnewall.com> wrote: > From: David Newall <davidn(a)davidnewall.com> > Subject: Re: execve for script don't return ENOEXEC, bug ? > To: "Valery Reznic" <valery_reznic(a)yahoo.com> > Cc: linux-kernel(a)vger.kernel.org > Date: Saturday, March 20, 2010, 11:41 AM > Valery Reznic wrote: > > [valery(a)localhost ~]$ cat a.sh #!/bin/sh > > echo "It's a.sh" > > [valery(a)localhost ~]$ cat b.sh #! ./a.sh > > echo "It's b.sh" > > [valery(a)localhost ~]$ [valery(a)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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Newall on 20 Mar 2010 14:00 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valery Reznic on 21 Mar 2010 04:40 --- On Sat, 3/20/10, David Newall <davidn(a)davidnewall.com> wrote: > From: David Newall <davidn(a)davidnewall.com> > Subject: Re: execve for script don't return ENOEXEC, bug ? > To: "Valery Reznic" <valery_reznic(a)yahoo.com> > Cc: linux-kernel(a)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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Stezenbach on 21 Mar 2010 15:20
(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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |