[Bug]: GIO_USE_VFS gets set to "local" for commands launched via flatpak-spawn

[ittayd]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.12.7

What Linux distribution are you using?

Ubuntu

Linux distribution version

Linux LT-IttayD 6.2.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 6 10:23:26 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

What architecture are you using?

x86_64

How to reproduce

I'm using the flatpak installation of wezterm, a terminal emulator.
For some reason, flatpak is started with GIO_USE_VFS=local in its environment (appears in /etc/profile.d/flatpak.sh and /etc/X11/Xsession.d/20flatpak).
Wezterm inherits this and passes to the shell it is running.
This makes gio not work for remote volumes. Unfortunately, the error is obscure ("volume doesn’t implement mount" in gio mount), so not trivial to identify.
I think that if GIO_USE_VFS should be 'local' for flatpak to work, it should not be passed to the processes it runs from packages.

Expected Behavior

the variable should not be passed

Actual Behavior

It is

Additional Information

No response

[smcv]

For some reason, flatpak is started with GIO_USE_VFS=local in its environment (appears in /etc/profile.d/flatpak.sh and /etc/X11/Xsession.d/20flatpak).

What is the exact contents of those files on your system?

On my Debian system (with a newer flatpak version), it's just GIO_USE_VFS=local flatpak --installations, which temporarily sets GIO_USE_VFS=local to run flatpak installations, but will not leave GIO_USE_VFS=local set for the rest of the shell session.

I'm using the flatpak installation of wezterm, a terminal emulator.

Have you tried using a different terminal emulator?

If programs you run from wezterm are inheriting GIO_USE_VFS=local, I think that's more likely to be coming from a source that is not /etc/profile.d/flatpak.sh or /etc/X11/Xsession.d/20flatpak.

[ittayd]

I have the same line and I don't think it sets the variable temporarily:
$ FOO=bar bash $ cat /tmp/foo.sh #! /bin/bash echo $FOO $ /tmp/foo.sh bar

Anyway, I found a zsh that had this environment var and it is a child of flatpak-session (as is my interactive shell). Maybe it is setting the var ?

[smcv]

Please provide the information I asked for: if you suspect /etc/profile.d/flatpak.sh and /etc/X11/Xsession.d/20flatpak are causing a problem, what is their exact contents on your system?

I found a zsh that had this environment var and it is a child of flatpak-session (as is my interactive shell)

Do you mean it's a child of flatpak-session-helper?

Does wezterm use flatpak-spawn --host to launch shells, etc. outside its sandbox?

If it does, I think it's more likely that this is caused by the g_setenv ("GIO_USE_VFS", "local", TRUE); in flatpak-session-helper. The session helper should probably be saving its initial environment variables at startup, and using those (instead of its current environment) when it starts subprocesses.

[ittayd]

The files in /etc have the same content as you.

Yes, it seems to be the child.

I don't know what wezterm does. But it sounds like g_setenv would cause this issue.

[smcv]

As I suspected, this seems to be a problem with the services that are used as a backend for flatpak-spawn. Your app probably uses flatpak-spawn --host (its backend is flatpak-session-helper), but the same issue exists when using flatpak-spawn (its backend is flatpak-portal). Fix proposed in #5577, which also contains simpler steps to reproduce the issue.

[smcv]

The use of GIO_USE_VFS in /etc/profile.d/flatpak.sh and /etc/X11/Xsession.d/20flatpak does not seem to be a problem here.

I have the same line and I don't think it sets the variable temporarily:

(outer shell) $ FOO=bar bash
(inner shell) $ cat /tmp/foo.sh
#! /bin/bash
echo $FOO
(inner shell) $ /tmp/foo.sh bar

Of course if you set GIO_USE_VFS for a parent process (in your case bash), it will inherit into child processes of that parent: that's how environment variables work. However, /etc/profile.d/flatpak.sh and /etc/X11/Xsession.d/20flatpak don't start any long-running processes with GIO_USE_VFS: they just run flatpak --installations, which lists all the available installations and then exits. A closer equivalent is this:

#!/bin/sh
unset FOO
echo "1"
FOO=bar env | grep '^FOO='
echo "2"
env | grep '^FOO='
echo "3"

which demonstrates that running a short-lived command with FOO=bar in the environment (between markers 1 and 2), like /etc/profile.d/flatpak.sh does, does not affect the environment given to subsequent commands (2 onwards).

[smcv]

A possible workaround would be for your terminal emulator (wezterm) to replace its current use of flatpak-spawn --host ... with flatpak-spawn --unset-env=GIO_USE_VFS --host ... when it launches a shell on the host system.