From unknown Sun Jun 22 00:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54587: chroot: incorrectly reporting ": no such file or directory" Resent-From: Kyle Glaws Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 26 Mar 2022 21:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 54587 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 54587@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164833001220051 (code B ref -1); Sat, 26 Mar 2022 21:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Mar 2022 21:26:52 +0000 Received: from localhost ([127.0.0.1]:54802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYDvw-0005DK-Ag for submit@debbugs.gnu.org; Sat, 26 Mar 2022 17:26:52 -0400 Received: from lists.gnu.org ([209.51.188.17]:46660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYDlk-0004w2-1E for submit@debbugs.gnu.org; Sat, 26 Mar 2022 17:16:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYDlj-0005hC-PK for bug-coreutils@gnu.org; Sat, 26 Mar 2022 17:16:19 -0400 Received: from [2607:f8b0:4864:20::102b] (port=44773 helo=mail-pj1-x102b.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nYDli-0005nO-2c for bug-coreutils@gnu.org; Sat, 26 Mar 2022 17:16:19 -0400 Received: by mail-pj1-x102b.google.com with SMTP id o6-20020a17090a9f8600b001c6562049d9so11834222pjp.3 for ; Sat, 26 Mar 2022 14:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=rcK6zGoTSqvzFHER8vuwepWQLFsikzjyHyniLZLataI=; b=B/lf4zPn9AvsWLc6GBrF5WaKSA26pA+ZFB50GNLdf8VdONmfG4SknO8eGovtU8QH8a Xow4eAloFh/EZLoAmIThAHwRFhkILKL9dkUeZql2hpuyBDnvLRXRIvXoCEcv1fZGqMRe KeZO/7HBpHQ3l38FdReuZn8fReJOCMTy/Qol1ffS1Vju74XLxyMwJTYJmu/GAF8tHkV1 qy5oWBpXl/YA+4Ycberu1fMOsgwIv/zj/h6enVF7qUyzfC2l4loQ+3dzMA+emBAw7Pg+ 3roN/qez/sKZZ30E3JS+0BQ6Lv/yO9OW9xsgfZModU6QQR57BOuI2phduv/YqA6wuyAZ Oq6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rcK6zGoTSqvzFHER8vuwepWQLFsikzjyHyniLZLataI=; b=XXfUceZeFOSEmuji2YUj7e32W1XlIMy1RK+QJ6WBz55msWKd4Ymh4HD5/UEfW0HUgj HN+73wGQXZYd/gXJvA8rJriE1BAYH5Jn1phNIEB+x8gDdqEZ+uCHAchKqty+Bida9Hxx WUuDMqK3xwFwjEe/8YJE8Br6wGzr0zGfZCvWZ/2xGAPzWla6vRkCLjYJBclcoAYOP58L Ty0VawrVkp3Go91Gve4wOeOcXiLfiH9N/i48K8QRnB86F4sj6tMqLO+8Fy4MmONqEdqq oInyE1tELFgO69B0VcxI4vVUJ/PP9DBhzhCNdH1xqBwPczPuGhKJ8siSCfqzfhihvIGB j6/w== X-Gm-Message-State: AOAM532B+3o3VR6ElbkZEV4eVLhGATHiHaH46d+/gVkFsbCVeKqEwUec IfEUOI6lU5yOWjQ0Kgx370SIArPSBc50NYi6O83Mb21MOUI= X-Google-Smtp-Source: ABdhPJwAFHTob99Tb8DPeDOBhyldGbv8foGj9wZF2opVQ/DpUkxU8LzDO2OIiZ0GZ1UwNKHUozCHxeJpaEbMdxQ2lk4= X-Received: by 2002:a17:90b:4d82:b0:1c7:438d:241f with SMTP id oj2-20020a17090b4d8200b001c7438d241fmr33253258pjb.161.1648329374069; Sat, 26 Mar 2022 14:16:14 -0700 (PDT) MIME-Version: 1.0 From: Kyle Glaws Date: Sat, 26 Mar 2022 17:16:04 -0400 Message-ID: Content-Type: multipart/alternative; boundary="000000000000d0777d05db259638" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::102b (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=kyle.glaws@gmail.com; helo=mail-pj1-x102b.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.2 (/) X-Mailman-Approved-At: Sat, 26 Mar 2022 17:26:51 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000d0777d05db259638 Content-Type: text/plain; charset="UTF-8" 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? --000000000000d0777d05db259638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I have encountered=C2=A0an issue with chroot (f= rom Coreutils version 9.0), but I think this email might fall more under th= e category of "comment" or maybe "question" rather than= "bug report", since it's not clear that the observed behavio= r is unintentional.

I have noticed that chroot will incorrectly repo= rt that a command could not be found, when in fact it is a shared library w= hich the command needs that=C2=A0could not be found, while the command itse= lf is actually present.

Example:
say you have the bare minimum de= pendencies to run 'bash' in some isolated directory:
$ cd ~/my_i= solated_env
$ ldd usr/bin/bash
...
libc.so.6 =3D> /lib/x86_64-l= inux-gnu/libc.so.6
$ sudo chroot . /usr/bin/bash -c "echo hello&quo= t; # 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 behavio= ur 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 c= onsidered misleading? Is there some practical reason for not being more spe= cific in this error message?
--000000000000d0777d05db259638-- From unknown Sun Jun 22 00:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54587: chroot: incorrectly reporting ": no such file or directory" Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sat, 26 Mar 2022 22:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54587 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Kyle Glaws , 54587@debbugs.gnu.org Received: via spool by 54587-submit@debbugs.gnu.org id=B54587.164833387726289 (code B ref 54587); Sat, 26 Mar 2022 22:32:01 +0000 Received: (at 54587) by debbugs.gnu.org; 26 Mar 2022 22:31:17 +0000 Received: from localhost ([127.0.0.1]:54841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYEwH-0006px-7W for submit@debbugs.gnu.org; Sat, 26 Mar 2022 18:31:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYEwF-0006pd-6U for 54587@debbugs.gnu.org; Sat, 26 Mar 2022 18:31:15 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 93591160112; Sat, 26 Mar 2022 15:31:08 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id h6Ibed9xDUnv; Sat, 26 Mar 2022 15:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C661316011F; Sat, 26 Mar 2022 15:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RDUIKh1gJM9f; Sat, 26 Mar 2022 15:31:06 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-19-248.fv.ks.cox.net [72.206.19.248]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B3241160112; Sat, 26 Mar 2022 15:31:05 -0700 (PDT) Message-ID: <9b306f3d-47d8-27c5-6038-e0b1287d8cd5@cs.ucla.edu> Date: Sat, 26 Mar 2022 17:31:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US References: From: Paul Eggert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 3/26/22 16:16, Kyle Glaws wrote: > 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). How? More details, please. From unknown Sun Jun 22 00:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54587: chroot: incorrectly reporting ": no such file or directory" Resent-From: Kyle Glaws Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sun, 27 Mar 2022 01:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54587 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Paul Eggert Cc: 54587@debbugs.gnu.org Received: via spool by 54587-submit@debbugs.gnu.org id=B54587.164834516311798 (code B ref 54587); Sun, 27 Mar 2022 01:40:01 +0000 Received: (at 54587) by debbugs.gnu.org; 27 Mar 2022 01:39:23 +0000 Received: from localhost ([127.0.0.1]:54984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYHsI-00034D-BG for submit@debbugs.gnu.org; Sat, 26 Mar 2022 21:39:22 -0400 Received: from mail-pl1-f169.google.com ([209.85.214.169]:35570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYGF7-0000TH-3q for 54587@debbugs.gnu.org; Sat, 26 Mar 2022 19:54:49 -0400 Received: by mail-pl1-f169.google.com with SMTP id y6so9228136plg.2 for <54587@debbugs.gnu.org>; Sat, 26 Mar 2022 16:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CUkfYdLEyYTuh9ku+DqEDajq2+7/xMw5bU7r+xd+A/c=; b=cKTvMc25J0YEe4RNgy22dkm/Sa5RJhT/VcSRaKcBTVrkSHXh3FlMmct+evTYAq7C93 48IP9bF2TiZimVhMnmCKgYsBmlz0JC51uiBrrvtQcBEi34WF/Tva4Yyc9JvBDciZyQOE ZxFlwUd6j3HV+EskmaS9psf7xEFCaqW4giKdGWwiQzhwoHIWm35yoScW7bGinRR//55/ ul/Jr8sDgq/ayHmvsWkxPHSlcG+J0F9FHnHV/gM3n6z24Ii3JTvoG+J/qky2uVDxjZdV SvvPS7GVhs99B+y/EWocBjubO2vysIkFYiAkHFfFTo1Y22A68QCmG6+G3WtH5NudLvGK X3hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CUkfYdLEyYTuh9ku+DqEDajq2+7/xMw5bU7r+xd+A/c=; b=mA6Hcih5J4gMhLIjZNfGW1BKEijfn61vDyoJdb1VpFTP3rH0E8otGaN27FN2+zaGKF m2rqq0XBxEbH9xPVcK1ttOdz/gQ4mwpRdblUdsoyaa7vEkLyPsraXqCr6ygIpaQHL6Ac bOLvZltiBxINPaLAnX8WbDW09g5jGAYZG07k197sVislcdnUeENXkcVezXQKpRHmjY/q zT0YtyDuyuqpOMBiHLuvxKjnD1duBRQ5OVUfFak6ITGRW2D2+mLeF4hG8k5cDMqhsm5W FPCbYcfHcjFfJa/kVvqKJ74d5U1FO63jKsTRAwsrba1IH1D1vjhjdmvemB1QG/sXhMNC LdVw== X-Gm-Message-State: AOAM531NuRUUyymxX+bua+wdgXvUfgHOTxPMutXqKYylciMzPVk1n1Iu RzvSwZJkC0EwbGX86IxAjr+b8reR8O2G4LpWgN8= X-Google-Smtp-Source: ABdhPJxke0X+WzNa9o787fptIiuOQOsSQSasgVS+9cAsTqhwFb+jtyIgZ0+VLH50CzyCZ1DAZWVbc2lGPop35qWVGYM= X-Received: by 2002:a17:90b:4d82:b0:1c7:438d:241f with SMTP id oj2-20020a17090b4d8200b001c7438d241fmr33803805pjb.161.1648338883142; Sat, 26 Mar 2022 16:54:43 -0700 (PDT) MIME-Version: 1.0 References: <9b306f3d-47d8-27c5-6038-e0b1287d8cd5@cs.ucla.edu> In-Reply-To: <9b306f3d-47d8-27c5-6038-e0b1287d8cd5@cs.ucla.edu> From: Kyle Glaws Date: Sat, 26 Mar 2022 19:54:34 -0400 Message-ID: Content-Type: multipart/alternative; boundary="00000000000099681f05db27cd90" X-Spam-Score: -0.0 (/) X-Mailman-Approved-At: Sat, 26 Mar 2022 21:39:20 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000099681f05db27cd90 Content-Type: text/plain; charset="UTF-8" Here are the last few lines in chroot.c::main for reference: ... /* Execute the given command. */ execvp (argv[0], argv); int exit_status = errno == ENOENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE; error (0, errno, _("failed to run command %s"), quote (argv[0])); return exit_status; } When the shared library is missing, execvp will set errno to ENOENT. In that event, it might be possible to stat the path to the command to confirm that the command does not exist. If stat says the path does *not* exist, the existing error message makes sense. If it *does* exist however, I'm not positive, but it might be safe to infer that the command is actually missing some dependency, and that this is the only other cause for an ENOENT. To take things further, it might be possible to iterate through the command's dependencies, and determine which specifically are missing, and indicate that in the error message. That last bit might be overly ambitious though, as I have no clue how it could be implemented. Perhaps by directly parsing the command's elf headers? I have not tried implementing any of this myself, but as I said, it does not seem impossible to at least slightly improve the error message for this case. I've roughly modified the above snippet to illustrate: ... /* Execute the given command. */ execvp(argv[0], argv); int exit_status = errno == ENOENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE; if (exit_status == EXIT_ENOENT && stat(argv[0]) == 0) { // the command exists fprintf(stderr, "'%s' is missing dependencies\n", argv[0]); return exit_status; // or possibly determine which dependencies are missing, and print those before exiting } error (0, errno, _("failed to run command %s"), quote (argv[0])); return exit_status; } On Sat, Mar 26, 2022 at 6:31 PM Paul Eggert wrote: > On 3/26/22 16:16, Kyle Glaws wrote: > > 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). > > How? More details, please. > > --00000000000099681f05db27cd90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are the last few lines in chroot.c::main for referenc= e:
=C2=A0 ...
=C2=A0 /* Execute the given command. =C2=A0*/
=C2=A0= execvp (argv[0], argv);

=C2=A0 int exit_status =3D errno =3D=3D ENO= ENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE;
=C2=A0 error (0, errno, _("= failed to run command %s"), quote (argv[0]));
=C2=A0 return exit_st= atus;
}

When the shared library is missing, execvp will set errno= to ENOENT. In that event, it might be possible to stat the path to the com= mand to confirm that the=C2=A0command does not exist. If stat says the path= does *not* exist, the existing error message makes=C2=A0sense. If it *does= * exist however, I'm not positive, but it might be safe to infer that t= he command is actually missing some dependency,=C2=A0and that this is the o= nly other cause for an ENOENT. To take things further, it might be possible= to iterate through the command's dependencies, and determine which spe= cifically are missing, and indicate that in the error message. That last bi= t might be overly ambitious though,=C2=A0as I have no clue how it could be = implemented. Perhaps by directly=C2=A0parsing the command's elf headers= ? I have not tried implementing any of this myself, but as I said, it does = not seem impossible to at least slightly improve the error message for this= case.

I've roughly modified the above snippet to illustrate:
=C2=A0 ...
=C2=A0 /* Execute the given command. */
=C2=A0 execvp= (argv[0], argv);

=C2=A0 int exit_status =3D errno =3D=3D ENOENT ? EX= IT_ENOENT : EXIT_CANNOT_INVOKE;

=C2=A0 if (exit_status =3D=3D EXIT_E= NOENT && stat(argv[0]) =3D=3D 0) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 // the command exists
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fprintf(= stderr, "'%s' is missing dependencies\n", argv[0]);
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return exit_status; // or possibly deter= mine which dependencies are missing, and print those before exiting
=C2= =A0 }

=C2=A0 error (0, errno, _("failed to run command %s"= ), quote (argv[0]));
=C2=A0 return exit_status;
}

On Sat, Mar 26= , 2022 at 6:31 PM Paul Eggert <egg= ert@cs.ucla.edu> wrote:
On 3/26/22 16:16, Kyle Glaws wrote:
> 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 sh= ared
> library is missing, not the executable itself).

How? More details, please.

--00000000000099681f05db27cd90-- From unknown Sun Jun 22 00:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#54587: chroot: incorrectly reporting ": no such file or directory" Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Sun, 27 Mar 2022 04:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54587 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Kyle Glaws Cc: 54587@debbugs.gnu.org Received: via spool by 54587-submit@debbugs.gnu.org id=B54587.164835690930474 (code B ref 54587); Sun, 27 Mar 2022 04:56:02 +0000 Received: (at 54587) by debbugs.gnu.org; 27 Mar 2022 04:55:09 +0000 Received: from localhost ([127.0.0.1]:55062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYKvk-0007vS-QI for submit@debbugs.gnu.org; Sun, 27 Mar 2022 00:55:08 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nYKvh-0007ur-Ig for 54587@debbugs.gnu.org; Sun, 27 Mar 2022 00:55:06 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1DD2116009E; Sat, 26 Mar 2022 21:54:59 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SM61OqE4RkTf; Sat, 26 Mar 2022 21:54:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2885816011F; Sat, 26 Mar 2022 21:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MbTv5MewBK9b; Sat, 26 Mar 2022 21:54:58 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-19-248.fv.ks.cox.net [72.206.19.248]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BF68C16009E; Sat, 26 Mar 2022 21:54:57 -0700 (PDT) Message-ID: Date: Sat, 26 Mar 2022 23:54:39 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US References: <9b306f3d-47d8-27c5-6038-e0b1287d8cd5@cs.ucla.edu> From: Paul Eggert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 3/26/22 18:54, Kyle Glaws wrote: > When the shared library is missing, execvp will set errno to ENOENT. In > that event, it might be possible to stat the path to the command to confirm > that the command does not exist. > That would lead to a race condition, in case the file in question is > removed or created between the time that execvp fails and stat is called. > > Plus: why should chroot be any different from other commands that > invoke execvp and then rely on errno to say why execvp failed? Will we > need to modify every command that invokes execvp? If so, this would > indicate a bug in execvp rather than in every command that uses execvp. >