From: Eric Biggers <ebiggers@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] common/filter: add _filter_bash()
Date: Sat, 18 Dec 2021 20:34:22 -0600 [thread overview]
Message-ID: <Yb6aLm5L+C7H3Z9P@quark.localdomain> (raw)
In-Reply-To: <Yb4V/GBZDjcXK9qo@mit.edu>
On Sat, Dec 18, 2021 at 12:10:20PM -0500, Theodore Ts'o wrote:
> On Wed, Dec 15, 2021 at 04:54:19PM -0800, Eric Biggers wrote:
> >
> > Doesn't this happen with any shell command passed to -c, not just commands that
> > run an executable? In the commands below which are causing the problem, it is
> > actually the 'echo' built-in being used, not an executable.
>
> Well.... it happens with all executables and *some* built-in commands
> which returns an error. (See the postscript for a case where the line
> number is printed.) In the case of an error opening the redirected
> standard output, such as permission denied, the difference does occur:
>
> Compare:
>
> % schroot -c buster-amd64 -- bash -c "echo foo >> /bin/bash"
> bash: /bin/bash: Permission denied
> % schroot -c buster-amd64 -- bash --version
> GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2019 Free Software Foundation, Inc.
> ...
>
> with
>
> % schroot -c bullseye-amd64 -- bash -c "echo foo >> /bin/bash"
> bash: line 1: /bin/bash: Permission denied
> % schroot -c bullseye-amd64 -- bash --version
> GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
> ...
>
> I just used the example of "bash -c /etc/passwd" because it was
> simpler, and because it would be easy to verify regardless of whether
> the command was executed as root or not. For example:
>
> % schroot -c bullseye-amd64 -u root -- bash -c "echo foo >> /bin/bash"
>
> would have succeeded (and corrupted /bin/bash in my chroot :-).
A good example that doesn't involve an executable would be
bash -c "echo foo > /"
... since that command redirection will always fail.
> I suppose I could have used the "schroot -c ..." example in the commit
> description, but that's a debian-specific command, and I chose to err
> on the side of something simpler and easier to replicate.
>
> If Eryu would prefer, I can resend with a modified commit description,
> or he can feel free to edit the commit description with the above
> example if he thinks it's clearer.
I'm more concerned about the misleading comment above _filter_bash(), not the
commit message which is less important. Anyway, it's not too important, but I
thought it was worth pointing out.
- Eric
next prev parent reply other threads:[~2021-12-19 2:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 17:04 [PATCH] common/filter: add _filter_bash() Theodore Ts'o
2021-12-16 0:54 ` Eric Biggers
2021-12-18 17:10 ` Theodore Ts'o
2021-12-19 2:34 ` Eric Biggers [this message]
2021-12-19 4:16 ` [PATCH -v2] " Theodore Ts'o
2021-12-19 5:24 ` Eric Biggers
-- strict thread matches above, loose matches on Subject: below --
2021-08-30 11:41 [PATCH] " Theodore Ts'o
2021-08-31 23:53 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yb6aLm5L+C7H3Z9P@quark.localdomain \
--to=ebiggers@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).