Re: execve() returns ENOENT when ld-linux.so isn't found

Re: execve() returns ENOENT when ld-linux.so isn't found

[drepper]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

On Wed, Mar 24, 2010 at 15:37, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Why not?
> It's an improvement IMO, although it could be better.

It's blatantly wrong.  There is no dynamic linker.  ENOEXEC means the file exists but is not of the right format.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 272 bytes --]

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Wed, Mar 24, 2010 at 11:45 PM,  <drepper@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 15:37, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>>
>> Why not?
>> It's an improvement IMO, although it could be better.
>
> It's blatantly wrong.  There is no dynamic linker.  ENOEXEC means the file
> exists but is not of the right format.

That sounds closer to the actual error than ENOENT.

ENOENT: The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter cannot be
found.
ENOEXEC: An executable is not in a recognized format, is for the wrong
architecture, or has some other format error that means it cannot be
executed.

ENOENT shouldn't be overloaded like this, as it's common meaning is:
file not found. So it shouldn't be returned if the argument to execve
is actually found.

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Luca Barbieri]

POSIX 2008 says, for exec*:

[ENOENT]
    A component of path or file does not name an existing file or path
or file is an empty string.
[ENOEXEC]
    The new process image file has the appropriate access permission
but has an unrecognized format.
[EINVAL]
    The new process image file has appropriate privileges and has a
recognized executable binary format, but the system does not support
execution of a file with this format.

None of these perfectly fit, but EINVAL seems the closest.
Note that ENOENT only specifies that the error happens for "not found"
problems in the function argument itself, so it is not really more
correct than the others.

Linux also defines ELIBACC (for a.out I believe):
#define ELIBACC         79      /* Can not access a needed shared library */

This also seems a possible candidate.

Not sure if it is safe to change this though, or what other systems do.

Re: execve() returns ENOENT when ld-linux.so isn't found

[Ulrich Drepper]

On Thu, Mar 25, 2010 at 14:00, Luca Barbieri <luca.barbieri@gmail.com> wrote:
> None of these perfectly fit, but EINVAL seems the closest.

No.  ENOENT is the right value.

Once again, read my first message.  The shell cannot just report the
error anyway since there can be many different reasons for the
problem.  If the dynamic linker is missing it has to be discovered and
then reported.  In that message the correct error code is ENOENT.

Don't try to change things which are as good as any other solution.
The error message alone is in no case sufficient.  Fix your shells.

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Fri, Mar 26, 2010 at 12:56 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> No.  ENOENT is the right value.
>
> Once again, read my first message.  The shell cannot just report the
> error anyway since there can be many different reasons for the
> problem.  If the dynamic linker is missing it has to be discovered and
> then reported.  In that message the correct error code is ENOENT.
>
> Don't try to change things which are as good as any other solution.
> The error message alone is in no case sufficient.  Fix your shells.

What about other apps that call execve?
Sounds like a lot of code duplication is needed.

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Luca Barbieri]

>> None of these perfectly fit, but EINVAL seems the closest.
>
> No.  ENOENT is the right value.

Not according to POSIX 2008, which does not explicitly specify this case.

Again, it says:
[ENOENT]
    A component of <i>path</i> or <i>file</i> does not name an
existing file or <i>path</i> or <i>file</i> is an empty string.

Here "path" and "file" refer to the argument to the C function and
"component" refers to the tokens obtained after splitting using "/" as
a separator.
POSIX 2008 doesn't talk at all about dependencies of the executables.

POSIX 2008 mandates EINVAL if you interpret "executable format" as
being "ELF executable with interpreter /lib/FOO" as opposed to just
"ELF", or if you interpret "architecture" as including the ELF
interpreter name in addition to the machine type.

By the way, is there any way to do this in the shell other than
including an ELF parser or assuming the ELF interpreter is missing if
the kernel returns ENOENT but the file exists and has an ELF
signature? (both of these solutions seem quite unsatisfactory)

Re: execve() returns ENOENT when ld-linux.so isn't found

[Ulrich Drepper]

On Fri, Mar 26, 2010 at 14:06, Luca Barbieri <luca.barbieri@gmail.com> wrote:
>>> None of these perfectly fit, but EINVAL seems the closest.
>>
>> No.  ENOENT is the right value.
>
> Not according to POSIX 2008, which does not explicitly specify this case.

That argumentation is bogus.  You wrote yourself, this situation isn't
(and cannot) be described in POSIX.  For such cases the any error
value is consistent with POSIX.


Again: any value is as good as any other.  The existing value works
and changing it breaks existing code.

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Fri, Mar 26, 2010 at 10:15 PM, Ulrich Drepper <drepper@gmail.com> wrote:
>> Not according to POSIX 2008, which does not explicitly specify this case.
>
> That argumentation is bogus.  You wrote yourself, this situation isn't
> (and cannot) be described in POSIX.  For such cases the any error
> value is consistent with POSIX.
>
>
> Again: any value is as good as any other.  The existing value works
> and changing it breaks existing code.

It didn't 'work' for me.
What code would break?

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Ulrich Drepper]

On Sat, Mar 27, 2010 at 04:50, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> It didn't 'work' for me.

You still don't get it?  No shell provides you with a correct error
message.  There is quite some work involved (reading program header,
finding the interpreter entry, checking the file) to give a meaningful
error message.  Changing the error code alone achieves nothing.


> What code would break?

At the very least the shells in Red Hat releases for many years.

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Sat, Mar 27, 2010 at 1:05 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Sat, Mar 27, 2010 at 04:50, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> It didn't 'work' for me.
>
> You still don't get it?  No shell provides you with a correct error
> message.  There is quite some work involved (reading program header,
> finding the interpreter entry, checking the file) to give a meaningful
> error message.  Changing the error code alone achieves nothing.

File not found is a very common error message with a pretty will
understood meaning. Overloading it in this way causes confusion.
Overloading another error code would avoid this confusion, especially
since it's far less used.

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Ulrich Drepper]

On Mon, Mar 29, 2010 at 07:40, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> File not found is a very common error message with a pretty will
> understood meaning. Overloading it in this way causes confusion.

Again and again: this is not the message the user should ever see.  On
its own.  Once you precede it with the message about the dynamic
linker not being found and the name the ENOENT string is the right
one.

Re: execve() returns ENOENT when ld-linux.so isn't found

[Andreas Schwab]

Olaf van der Spek <olafvdspek@gmail.com> writes:

> File not found is a very common error message with a pretty will
> understood meaning.

And perfectly applicable here (as you write yourself in the subject).

> Overloading another error code would avoid this confusion, especially
> since it's far less used.

Changing a well understood error number into a totally misleading one
only increases confusion.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Mon, Mar 29, 2010 at 6:00 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Olaf van der Spek <olafvdspek@gmail.com> writes:
>
>> File not found is a very common error message with a pretty will
>> understood meaning.
>
> And perfectly applicable here (as you write yourself in the subject).

No, it's not. It does not apply to the argument of the function called.

>> Overloading another error code would avoid this confusion, especially
>> since it's far less used.
>
> Changing a well understood error number into a totally misleading one
> only increases confusion.

Why is it totally misleading? The proposed new one is actually very close.

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Luca Barbieri]

> That argumentation is bogus.  You wrote yourself, this situation isn't
> (and cannot) be described in POSIX.  For such cases the any error
> value is consistent with POSIX.

Sure, but that means POSIX also does not forbid changing it.

> Again: any value is as good as any other.  The existing value works
> and changing it breaks existing code.

Yes, this is an argument in favor of leaving it as is.

> Changing the error code alone achieves nothing.

If you were to change it to a new error value, such that
strerror(errno) == "unable to open ELF interpreter" (or similar), that
would just work.

The problem is that would only work after upgrading glibc, and would
probably break the error reporting code in RH shells if only the
kernel is upgraded.

A possibly better option is to add the ability to the kernel to report
extended error strings (was proposed some time ago), and use that.

It's a small issue, but I recently stumbled on it when running an x86
binary on an x86-64 machine lacking the compat libraries, and it's
quite suprising at first to have the shell claim the file does not
exist when it clearly does (and would be even more so for people who
don't know anything about executables or ELF).

The idea of parsing the ELF file in the shell seems quite ugly, since
you need to add a non-trivial piece of code at least to all shells and
all graphical file managers.
glibc itself could conceivably provide functions to do that
(strerror_for_exec* or exec*_with_extended_error ?).

execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

Hi,

When you try to execute an x86 binary on a x64 system, execve()
returns ENOENT when ld-linux.so isn't found
Wouldn't ENOEXEC be more appropriate?

> An executable is not in a recognized format, is for the wrong architecture, or has some other format error that means it cannot be executed.

This just doesn't make any sense:

$ ls -l
-rwxr-xr-x 1 olaf olaf 560165 2010-03-18 15:21 xwis
$ ./xwis
-bash: ./xwis: No such file or directory

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Thu, Mar 18, 2010 at 3:42 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Hi,
>
> When you try to execute an x86 binary on a x64 system, execve()
> returns ENOENT when ld-linux.so isn't found
> Wouldn't ENOEXEC be more appropriate?
>
>> An executable is not in a recognized format, is for the wrong architecture, or has some other format error that means it cannot be executed.
>
> This just doesn't make any sense:
>
> $ ls -l
> -rwxr-xr-x 1 olaf olaf 560165 2010-03-18 15:21 xwis
> $ ./xwis
> -bash: ./xwis: No such file or directory

This is the right list, isn't it?

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[drepper]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Thu, Mar 18, 2010 at 07:42, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> $ ls -l
> -rwxr-xr-x 1 olaf olaf 560165 2010-03-18 15:21 xwis
> $ ./xwis
> -bash: ./xwis: No such file or directory

Your shell should handle this.  I'm not sure whether it's in the upstream bash (it should be) but I wrote a long, long time ago a patch which produces better messages.  On my system I get:

$ ./u
bash: ./u: /some/path/does-not-exist: bad ELF interpreter: No such file or directory


It doesn't really matter what the kernel returns.  The shell should do its job and at least the RHEL/Fedora version does it for a long time now.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 272 bytes --]

Re: execve() returns ENOENT when ld-linux.so isn't found

[Olaf van der Spek]

On Wed, Mar 24, 2010 at 2:49 PM,  <drepper@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 07:42, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>>
>> $ ls -l
>> -rwxr-xr-x 1 olaf olaf 560165 2010-03-18 15:21 xwis
>> $ ./xwis
>> -bash: ./xwis: No such file or directory
>
> Your shell should handle this.  I'm not sure whether it's in the upstream

Why?
And why can't the kernel returned the more appropriate ENOEXEC?

> bash (it should be) but I wrote a long, long time ago a patch which produces
> better messages.  On my system I get:
>
> $ ./u
> bash: ./u: /some/path/does-not-exist: bad ELF interpreter: No such file or
> directory
>
>
> It doesn't really matter what the kernel returns.  The shell should do its
> job and at least the RHEL/Fedora version does it for a long time now.

That should be pushed upstream then.

Olaf

Re: execve() returns ENOENT when ld-linux.so isn't found

[drepper]

[-- Attachment #1: PGP/MIME version identification --]
[-- Type: application/pgp-encrypted, Size: 11 bytes --]

[-- Attachment #2: OpenPGP encrypted message --]
[-- Type: application/octet-stream, Size: 1893 bytes --]

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)

hQIOA1UJdQ8H+mVQEAf/XvycOn63wUuy1bpgUDatuhIxUDgCjeI64uM4mK90qtP1
XI8c3DkfK5WR0ZCIJzm8GVVITZU/YTaS64SsivPnUxppozModhOy8Rzr5+bItDD9
yswAlLvAdB9kDJ+Mc8OoP6th5zIxr1GEfSNX5EnNTlzSBP9d3+CR9emOUm2eNMgl
UfKCRhTSC8RMRYHU8DtffakhTQho6OK/UEoJxPzoNi+IYYmI0NZYlQITO9x7q02I
cNmIvtMj2n41zzsjXtpvmHJgIwr3b+zpzaz0itcbofNiGR/G58x5C33WWXN/iL/F
DW+lN7m3vuZfJXQbDVYyqsxlgM+S6aOCPqtMuzeBVgf/QQPoLNCtfzc5PEeaY9mD
SHc3TTlVF6kogXLD8WCNOKsRSMrRzUqMbQc8wsDSesnk6XPUz8faHXK42pIWppR2
rLkQldcVKEqxiZLud1S5c7LroLvAg0FFgOZCg3c0/subT+3jALmtBajHCfX8Mvp0
rRlSKZF3Vjm5b9wNkAHUQ4672lL1rjVtR5ZHNmULgO0POvxAD4pOToSEg5lpzCBz
ynQC12Ycvw5tJNzthNzk6rleA6lwmepNgvNQE7ky5Ihj7ewBEFge+eXEcg26v7qc
0DZ6Q44veL3rEhkDI79F5GskeOuPl9WXavzE8VZNbP1/MJTbr4UzE1Ejn5IQ7OW6
lNLpARM77RvjG3fpyDCWtkEihu7n+jz1xxjg3IhqOHaBzSod6qUCEKfmCAUS/PT6
DrLWF2tffYDtGTZL30CvPGuEZBJgyWiqrFitjIs+VbcsKKvcF/q9/c8rZCpr+/VT
ET2FU4WgUpDjubHBQ1iOwCfLfEqbmddkBfSG4jLvNE1iUgvaEt8bUY7dTzgDm6pA
8Gc/zUpb8sT/eAJwMwo6+xmHavi0PEwhUI6P2Rfa7WyJm9FnmIRkMG50E8Q6lbSw
dfkaASiCenNFY88HuZB7Yqj/aEfgs733hTTksz3t+BHQG+iUDbuJYvhVEDYxdjvk
b0lVjISCVzcUMjwfSWJwPSjuh5PMC9qwLNP7D8FwQcmKC+BvO0/jUfDiiezHvj+h
qIpu4GfQxHFr7ctFIIgDXpZJ58ze8fDYcWd7AFg29VI4reM2N4O4UVJvJvGRwUPX
ENXKjsDMzwdJCv66q21Y37kF1xsolJh+sVJIleFH+UK8NKKlSspOyDsY8Sw5H4Rx
OlIGuj7EWqHlv6OOnp75u6P8TI7VIMnzAodmjywsCy08M85r2Du3w5IRxKcMEbiW
l1Fds59AqTjSe6b+DAsjlEP4wIMouRzoKYNmxoH3CXT1DL06SXohIIlbA3P5jj35
hWjDmkzf++ut3/CBwnAWufwe6D0uxrJzWqCJe3cJqgXurGjAIkXerEPqE7ORLivd
Nd/c0tCIe76IwwNNYGSxym5mXtJdQsAQSrV0ZKafIJAyUQDUUISLiydKCyd3z8QR
1GzmouWjlliV28giW0tq5ggFgCS7DKqbwl0EtNE+gr9LMkh8sbeftGOOQPXLsAE0
eLH21dedSZAYGdWJi9+La3OjN1bKwk103eTLGGLmODCG5m1kz6XcmkFw7+tYVQy/
jIdnpYvL+O7yLmqxQGRTNpIHOT7vtQ/WFBilKSG2GsPN+Ul288J6BdacCsDRycJw
bO5Mg6IgZF27sGAHkUfGQp1xJtvbvHw=
=wfic
-----END PGP MESSAGE-----