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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/