DISPLAY problem with zsh + fvwm + firejail

DISPLAY problem with zsh + fvwm + firejail

[Dominik Vogt]

Running commands in firejail (an enhanced sandbox similar to
chroot), there is a problem with a certain way of starting
programs.

Working setup:
--------------

 # Running zsh inside an Rxvt managed by fvwm.
 $ firejail --debug set

Shows (with some added debug output), that zsh was used to run
"set", and that the display variable ist set:

  # args passed to execvp by firejail
  DISPLAY=':0'
  arg0: '/usr/bin/zsh'
  arg1: '-c'
  arg2: ''set' '
  # output of set shell builtin
  DISPLAY=':0'

Failing setup:
--------------

Run the command by the window manager.  Make a menu entry or open
FvwmConsole and type

  exec firejail --debug set

(exec is fvwm's command to run an external command).  Now, the
DISPLAY is set to an empty string:

  # args passed to execvp by firejail
  DISPLAY=':0'
  arg0: '/usr/bin/zsh'
  arg1: '-c'
  arg2: ''set' '
  # output of set shell builtin
  DISPLAY=''     <-------- empty string

--

I can't firgure out what's going on.  For some reason, DISPLAY is
set to an empty string between the final execvp() call in firejail
and the place that uses the value, and the shell may or may not be
involved in this problem.  Note that the same occurs if any shell
is set explicitly:

  exec firejail --debug bash -c xterm -> fails

But it works fine if firejail is told to omit the shell:

  exec firejail --debug xterm -> works

--

One more detail about the way fvwm calls external programs:

  rxvt
  -> zsh
  -> firejail
  -> execvp zsh -c 'firejail command'
  -> zsh
  -> firejail
  -> execvp
  -> zsh -c 'command'
  -> exec?
  -> command
  GOOD

 fvwm
  -> execvp
  -> sh -c 'firejail ...'
  -> sh
  -> firejail
  -> execvp zsh -c 'command'
  -> zsh
  -> exec?
  -> command
  BAD

(Note that you can tell fvwm to use zsh nstead of sh with
"execuseshell /bin/zsh".  This doesn't change anything.)

So, what is the cause of the different bevaviour and/or how can I
debug it?

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt

Re: DISPLAY problem with zsh + fvwm + firejail

[dana]

On 1 Jan 2020, at 14:58, Dominik Vogt <dominik.vogt@gmx.de> wrote:
> I can't firgure out what's going on.  For some reason, DISPLAY is
> set to an empty string between the final execvp() call in firejail
> and the place that uses the value, and the shell may or may not be
> involved in this problem.  Note that the same occurs if any shell
> is set explicitly:

I have absolutely no experience with fvwm or firejail, but:

In the first place, i don't understand what your output means when it says
that DISPLAY=:0 is passed as an argument to execvp(). execvp() doesn't take
environment variables as arguments. Is it using something in between, like env
or sh, to run it? Or is it just worded imprecisely?

Assuming the latter, could it be that you have some kind of shared file, like
/etc/environment, that shells on your system are configured to run on
start-up? And maybe that's clearing DISPLAY based on other environment
variables or whatever? That seems like a silly thing to do, but if you export
a variable and then it's unset/changed when you check it from within the
shell, that's the first thing that comes to mind. (Excepting a few special
variables that the shell uses for itself, obv.)

Does it show the correct value if you just run env instead of zsh? If not, i
think that would mean it's not actually exporting it the way it's suggesting
it is. If so, something running in the shell unsetting it seems more likely.

Anyay, you can run zsh with -x to see what it might be doing before the set
command. You might also try it with -f (to disable sourcing start-up files)

dana

Re: DISPLAY problem with zsh + fvwm + firejail

[Dominik Vogt]

On Wed, Jan 01, 2020 at 08:16:34PM -0600, dana wrote:
> On 1 Jan 2020, at 14:58, Dominik Vogt <dominik.vogt@gmx.de> wrote:
> > I can't firgure out what's going on.  For some reason, DISPLAY is
> > set to an empty string between the final execvp() call in firejail
> > and the place that uses the value, and the shell may or may not be
> > involved in this problem.  Note that the same occurs if any shell
> > is set explicitly:
>
> I have absolutely no experience with fvwm or firejail, but:
>
> In the first place, i don't understand what your output means when it says
> that DISPLAY=:0 is passed as an argument to execvp(). execvp() doesn't take
> environment variables as arguments.

Not as argument, but it preserves the contents of the "environ"
global variable so that the new executable uses the same
variables.

 Is it using something in between, like env
> or sh, to run it? Or is it just worded imprecisely?

> Assuming the latter, could it be that you have some kind of shared file, like
> /etc/environment, that shells on your system are configured to run on
> start-up?

Sure.

> And maybe that's clearing DISPLAY based on other environment
> variables or whatever?

No, the shell does not clear it.  The contents of DISPLAY are
overwritten between the final execvp() of firejail (i.e. they're
still there right before the call).  But the executed binary gets
an empty value.

> That seems like a silly thing to do, but if you export
> a variable and then it's unset/changed when you check it from within the
> shell, that's the first thing that comes to mind. (Excepting a few special
> variables that the shell uses for itself, obv.)

DISPLAY is of course exported, otherwise *nothing* that ist
started from the window manager would work.

> Does it show the correct value if you just run env instead of zsh?

No, it's also empty.  Note that firejail automatically runs the
command from a shell (zsh in this case) if its not explicitly told
otherwise with

  $ firejail --shell=none foo

Without hte shell, the value is fine.

> If not, i think that would mean it's not actually exporting it
> the way it's suggesting it is. If so, something running in the
> shell unsetting it seems more likely.

But "exporting" variables is a concept of the shell, right?  So an
execvp() in a random program knows nothing about "exporting"
variables - the called executable just inherits the whole
environment(?).

> Anyay, you can run zsh with -x to see what it might be doing before the set
> command. You might also try it with -f (to disable sourcing start-up files)

Okay, found it.  I've some decades old code in /etc/zsh/zshenv to
unset the DISPLAY when running on a console.  Something about X
being slow on AIX ages ago, can't really remember.

  if [ "$TERM" = linux ] ; then
    export DISPLAY=

Which kicks in here because the window manager was started from the
console with the value TERM=linux.   :-/

Thanks for the hints.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt

Re: DISPLAY problem with zsh + fvwm + firejail

[dana]

On 1 Jan 2020, at 20:51, Dominik Vogt <dominik.vogt@gmx.de> wrote:
> No, it's also empty.  Note that firejail automatically runs the
> command from a shell (zsh in this case) if its not explicitly told
> otherwise

Oh, i see. That should have been obvious from `exec firejail --debug set`, but
somehow i missed it. That explains why other shells were affected.

On 1 Jan 2020, at 20:51, Dominik Vogt <dominik.vogt@gmx.de> wrote:
> But "exporting" variables is a concept of the shell, right?  So an
> execvp() in a random program knows nothing about "exporting"
> variables - the called executable just inherits the whole
> environment(?).

You can manipulate the environment from any C application with setenv(),
execve(), &c. But it sounds like in this case firejail is just passing it
through like you said. Glad you found it

dana