GNU bug report logs - #54587
chroot: incorrectly reporting "<command>: no such file or directory"

Previous Next

Full log

View this message in rfc822 format

From: Kyle Glaws <kyle.glaws <at> gmail.com>
To: 54587 <at> debbugs.gnu.org
Subject: bug#54587: chroot: incorrectly reporting "<command>: no such file or directory"
Date: Sat, 26 Mar 2022 17:16:04 -0400

[Message part 1 (text/plain, inline)]

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?

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.