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
