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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 21 Mar 2010 20:16:19 +0100
From:	Johannes Stezenbach <js@...21.net>
To:	Valery Reznic <valery_reznic@...oo.com>
Cc:	David Newall <davidn@...idnewall.com>,
	linux-kernel@...r.kernel.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	linux-man@...r.kernel.org
Subject: Re: execve for script don't return ENOEXEC, bug ?

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