Proton 5.13 breaks with custom XAUTHORITY environment variable/location

[sk8ersteve]

Proton 5.13

I'm using Xorg (obviously) and after updating to Proton 5.13, all my games were broken. My log showed the following 3 indications.
No protocol specified err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.
I eventually figured out that this was caused by my custom Xauthority file location (export XAUTHORITY="$XDG_RUNTIME_DIR/Xauthority" in .profile). Disabling that setting fixed the problem but I think it should be possible to use Proton 5.13 with a custom Xauthority location just as I could prior to 5.13.

[kisak-valve]

Hello @sk8ersteve, can you check if a native linux game set to run with the "Steam Linux Runtime" compatibility tool is equally affected?

[sk8ersteve]

Hello @sk8ersteve, can you check if a native linux game set to run with the "Steam Linux Runtime" compatibility tool is equally affected?

It doesn't work. Same sort of behavior: I hit play and it tries to start but doesn't. I can't get the proton log though. The steam log shows these errors:
pressure-vessel-wrap[16361]: Not mounting "/usr/share/libdrm" over non-directory file or nonexistent path "/home/steve/git-repos/dotfiles/.local/share/Steam/steamapps/common/SteamLinuxRuntime/scout_0.20201007.1/files/share/libdrm" bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system

Also, this issue still occurs even when I don't set $XAUTHORITY as described.

[kisak-valve]

Let's treat this as a pressure-vessel issue until we get a stronger indication that this issue is from Proton and not from Steam Linux Runtime - Soldier, which is the container environment that Proton 5.13 is running on top of.

[sk8ersteve]

It seems it’s definitely not a pressure-vessel issue if non-linux games work perfectly fine when my XAUTHORITY variable is set as the default location (/home/steve/.Xauthority) and I don’t get the same pressure vessel errors when it is set to the custom location.

[kisak-valve]

Your last comment doesn't make sense? Can you re-read it and rephrase that.

[TTimo]

We have identified a problem in pressure-vessel's bwrap binary that is causing this. Will be fixed in a future update of the soldier runtime.

[sk8ersteve]

Your last comment doesn't make sense? Can you re-read it and rephrase that.

Yes so I’m saying I have two distinct issues. Problem 1, when I run a non-Linux game it works with a default XAUTHORITY setting, but when I use my custom XAUTHORITY setting, it yields xorg related errors in the proton log and fails to open the game. Problem 2, when I run a native Linux game in the “Steam Linux runtime”, I get a pressure vessel error in the general steam log, and this happens with either XAUTHORITY setting. This second issue also happens a lot faster in the whole startup process, but I’m not worried about problem 2 in this thread. I could be wrong but I’m having a hard time imagining how these two are related.

[sk8ersteve]

We have identified a problem in pressure-vessel's bwrap binary that is causing this. Will be fixed in a future update of the soldier runtime.

Does this address the XAUTHORITY file issue too? @TTimo

[TTimo]

You may be right. The fix we are working on is a compatibility problem with Wayland, we'll have to retest once that's out to see if XAUTHORITY edits are still a problem.

[smcv]

Workaround for XAUTHORITY issues:

On some (all?) systems, this can be solved by running xhost +si:localuser:$(id -nu) to tell your X11 server to accept uid-based access control (like Wayland and D-Bus), as an alternative to token-based access control (which is how XAUTHORITY works). Recent versions of GNOME's gdm do this automatically, but not everything else does.

This is believed to be secure on general-purpose systems, unlike xhost + (which is completely insecure, never use it).

The only situation where xhost +si:localuser:$(id -nu) would be unsafe is if you have untrusted processes running with the same uid as processes you want to protect. However, the design of Unix generally assumes that there is no trust boundary between processes with the same uid, so in that situation there are lots of other ways for the untrusted processes to attack the processes you want to protect (for example via D-Bus, systemd, ptrace, or files in your home directory).

The fix we are working on is a compatibility problem with Wayland

More specifically it's a compatibility problem with very recent GNOME releases in Wayland mode, but we think the root cause is probably the same as the root cause of these XAUTHORITY issues: wrong precedence in the way we merge environment variables from the host system with environment variables that need to be modified for the container.

[smcv]

Problem 1, when I run a non-Linux game it works with a default XAUTHORITY setting, but when I use my custom XAUTHORITY setting, it yields xorg related errors in the proton log and fails to open the game

Let's treat that as the scope of this issue report. Using the default XAUTHORITY path is a workaround for this. My previous comment describes a different workaround that will probably also work.

Problem 2, when I run a native Linux game in the “Steam Linux runtime”, I get a pressure vessel error in the general steam log, and this happens with either XAUTHORITY setting

Please open a separate issue for this, and mention bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system in the title. The information requested in https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md would be useful for this issue.

It seems like this is affecting the Steam Runtime 1 'scout' container used for native Linux games, but not the Steam Runtime 2 'soldier' container that is (currently) only used for Proton 5.13. I'd like to get some more information about this, so we can either get it solved, or be confident that it won't affect soldier and de-prioritize it.

[kisak-valve]

Hello @sk8ersteve, per "steam-runtime-tools: pick the correct DISPLAY and XAUTHORITY, fixes Gnome+Wayland and related problems (steam-runtime#283)" in the 2020-10-23 Steam client update and corresponding Steam Linux Runtime - Soldier update, please retest this issue.

[sk8ersteve]

It works!

[sk8ersteve]

Problem 2, when I run a native Linux game in the “Steam Linux runtime”, I get a pressure vessel error in the general steam log, and this happens with either XAUTHORITY setting

Please open a separate issue for this, and mention bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system in the title. The information requested in https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md would be useful for this issue.

It seems like this is affecting the Steam Runtime 1 'scout' container used for native Linux games, but not the Steam Runtime 2 'soldier' container that is (currently) only used for Proton 5.13. I'd like to get some more information about this, so we can either get it solved, or be confident that it won't affect soldier and de-prioritize it.

I couldn't reproduce this issue after updating so I'm guessing it was all fixed with the latest update. Also thank you guys so much for the work you put in dealing to all these issues for the Linux community!

[smcv]

I couldn't reproduce this issue after updating so I'm guessing it was all fixed with the latest update

I'm slightly concerned that we don't know what change fixed this (none of the fixes in the recent update seem relevant to /usr/lib32/gconv) - but we can always come back to it if it recurs.