* DISPLAY problem with zsh + fvwm + firejail @ 2020-01-01 20:58 Dominik Vogt 2020-01-02 2:16 ` dana 0 siblings, 1 reply; 4+ messages in thread From: Dominik Vogt @ 2020-01-01 20:58 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DISPLAY problem with zsh + fvwm + firejail 2020-01-01 20:58 DISPLAY problem with zsh + fvwm + firejail Dominik Vogt @ 2020-01-02 2:16 ` dana 2020-01-02 2:51 ` Dominik Vogt 0 siblings, 1 reply; 4+ messages in thread From: dana @ 2020-01-02 2:16 UTC (permalink / raw) To: dominik.vogt; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DISPLAY problem with zsh + fvwm + firejail 2020-01-02 2:16 ` dana @ 2020-01-02 2:51 ` Dominik Vogt 2020-01-02 3:18 ` dana 0 siblings, 1 reply; 4+ messages in thread From: Dominik Vogt @ 2020-01-02 2:51 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DISPLAY problem with zsh + fvwm + firejail 2020-01-02 2:51 ` Dominik Vogt @ 2020-01-02 3:18 ` dana 0 siblings, 0 replies; 4+ messages in thread From: dana @ 2020-01-02 3:18 UTC (permalink / raw) To: dominik.vogt; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-02 3:17 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-01 20:58 DISPLAY problem with zsh + fvwm + firejail Dominik Vogt 2020-01-02 2:16 ` dana 2020-01-02 2:51 ` Dominik Vogt 2020-01-02 3:18 ` dana
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ 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).