Subject: chroot: incorrectly reporting "<command>: no such file or directory"

From: Kyle Glaws <[email-masked]>
Date: Sat, 26 Mar 2022 17:16:04 -0400

Hello,
I have encountered an issue with chroot (from Coreutils version 9.0), but I
think this email might fall more under the category of "comment" or maybe
"question" rather than "bug report", since it's not clear that the observed
behavior is unintentional.

I have noticed that chroot will incorrectly report that a command could not
be found, when in fact it is a shared library which the command needs
that could not be found, while the command itself is actually present.

Example:
say you have the bare minimum dependencies to run 'bash' in some isolated
directory:
$ cd ~/my_isolated_env
$ ldd usr/bin/bash
...
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
$ sudo chroot . /usr/bin/bash -c "echo hello" # successful execution
hello
$ rm ./lib/x86_64-linux-gnu/libc.so.6 # delete shared library that bash
needs
$ sudo chroot . /usr/bin/bash -c "echo hello" # unsuccessful execution
chroot: failed to run command '/usr/bin/bash': No such file or directory

Looking at the source code in chroot.c, it doesn't seem impossible to add
some logic that makes this error message more accurate (i.e. that a shared
library is missing, not the executable itself). Unless this behaviour is
well known and intentional (which wouldn't surprise me). In which case, my
question would be: why is that? Is this error message not to be considered
misleading? Is there some practical reason for not being more specific in
this error message?