Re: [PATCH] common/filter: add _filter_bash()

["Theodore Ts'o" <tytso@mit.edu>]

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 :-).

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.

Cheers,

				- Ted

P.S. The 5.1 behavior is actually a bit more consistent, since other
errors involving built-ins do actualy print a line number (although
not a *consistent* line number between bash 5.0 and 5.1:

% schroot -c buster-amd64 -- bash -c "jobs --bad-option"
bash: line 0: jobs: --: invalid option
...

vs

% schroot -c bullseye-amd64 -- bash -c "jobs --bad-option"
bash: line 1: jobs: --: invalid option
...

So the changes in Bash 5.1 error reporting does have something to
recommend itself in terms of self-consistency, but it is a bit of pain
for xfstests, where any changes in output requires extra filter
hacking!