Bugzilla – Bug 1137491
flatpak/snap: "Invalid MIT-MAGIC-COOKIE-1 key" after resume (network/hostname changes?)
Last modified: 2020-08-25 10:38:31 UTC
After locking the screen I cannot run some application and I get messages like: Invalid MIT-MAGIC-COOKIE-1 key cannot open the display To fix this issue I need to run: xhost +local: Note that I have an nvidia graphics card with nidia drivers installed.
It looks like mostly/only(?) flatpack programs are affected.
(In reply to Kacper Pluta from comment #1) > It looks like mostly/only(?) flatpack programs are affected. Example? How to reproduce this? Is this related to screen locking at all? You did unlock the screen before running the flatpack program (maybe somewhat remotely), right?
The typical scenario for me is as follows. 1. I lock the screen and turn off the display (maybe part of the problem?) 2. Once I am back in the office I turn on the display and unlock the screen 3. Try to run e.g. signal or slack (flatpack) and they do not start 4. I do xhost +local: and then everything works again I have not checked other programs yet. I will do this next time the problem will happen. There is nothing remotely going on.
Hmm. Does the output of xauth list echo $DISPLAY look different before and after the lock? In case they do, what are the differences? Feel free to change the cookies themselves ... If not and other regular X programs still work afterwards I would blame flatpack here ...
Perhaps it is the same reason, that caused messages like this on my systems. Excerpt from my posts in the openSUSE mailingl list: ------------------------------------------------------------------------- What are the contents of /etc/hostname? Only the name of your machine or the fqdn? If it is the fqdn, try with the name only and - if necessary for some other apps - set "127.0.1.1 <fqdn> <name>" in /etc/hosts. Reboot after that and see, if it helped. From the man page for /etc/hostname: The /etc/hostname file configures the *name* of the local system that is set during boot using the sethostname(2) system call. It should contain a single newline-terminated hostname string. Comments (lines starting with a `#') are ignored. The hostname may be a free-form string up to 64 characters in length; however, *it is recommended that it consists only* *of 7-bit ASCII lower-case characters and no spaces or dots*, and limits itself to the format allowed *for DNS domain name labels*, even though this is not a strict requirement. It cost me 2 weeks to find out, that during boot process the combination of kernel, systemd and NetworkManager behaviour led to two changes for the hostname - the first one was set by the kernel without the domain part during pre boot, the second one was set by NetworkManager, who got it from systemd-hostnamed, who in turn read it from /etc/hostname. If the logon manager (sddm, ...) was up before the second change took place, it created a cookie, that gets written into .Xauthority after logon. When the hostname changes for the second time after logon, the cookie isn't valid any longer, because it contains the name without the domain part, but now the machine's name contains the domain part. -------------------------------------------------------------------------
@Michael Hirmke Sounds interesting! So it would be good to see also the output of hostname -A before and after locking/unlocking the screen.
I'm not really sure, if locking the screen can cause this. Due to my investigation it has something to do with networking. Perhaps the client is losing network (wifi?) connectivity due to inactivity.
(In reply to Stefan Dirsch from comment #6) > @Michael Hirmke > Sounds interesting! So it would be good to see also the output of > > hostname -A > > before and after locking/unlocking the screen. Stefan, only the hostname -A is different before and after. Before --- xauth list: linux-wged/unix:0 MIT-MAGIC-COOKIE-1 3f2d2f831f6d686da2f947141856c5cf PC-CGGC-KACPERP/unix:0 MIT-MAGIC-COOKIE-1 13b48f9fe9bb276b397403d023689eb2 pc-cggc-kacperp/unix:1 MIT-MAGIC-COOKIE-1 9a034a2c0579073d7e5d627c620a9634 PC-CGGC-KACPERP.CS.Technion.ac.il/unix:0 MIT-MAGIC-COOKIE-1 e9aa013fa0917fad33e1633a1ed6d44e pc-cggc-kacperp/unix:0 MIT-MAGIC-COOKIE-1 aaa0c2f917e4ecc57f8d4b8ff9c33801 echo $DISPLAY: :0 hostname -A: pc-cggc-kacperp.cs.technion.ac.il pc-cggc-kacperp.cs.technion.ac.il After ---- xauth list: linux-wged/unix:0 MIT-MAGIC-COOKIE-1 3f2d2f831f6d686da2f947141856c5cf PC-CGGC-KACPERP/unix:0 MIT-MAGIC-COOKIE-1 13b48f9fe9bb276b397403d023689eb2 pc-cggc-kacperp/unix:1 MIT-MAGIC-COOKIE-1 9a034a2c0579073d7e5d627c620a9634 PC-CGGC-KACPERP.CS.Technion.ac.il/unix:0 MIT-MAGIC-COOKIE-1 e9aa013fa0917fad33e1633a1ed6d44e pc-cggc-kacperp/unix:0 MIT-MAGIC-COOKIE-1 aaa0c2f917e4ecc57f8d4b8ff9c33801 echo $DISPLAY :0 hostname -A: pc-cggc-kacperp.cs.technion.ac.il Michael, in fact, you are right I think.
Hmm. No idea why hostname result changes after unlocking the screen.
(In reply to Stefan Dirsch from comment #9) > Hmm. No idea why hostname result changes after unlocking the screen. I think this is not unlocking/locking but the fact that the power settings are switching the eth card off.
(In reply to Kacper Pluta from comment #10) > (In reply to Stefan Dirsch from comment #9) > > Hmm. No idea why hostname result changes after unlocking the screen. > > I think this is not unlocking/locking but the fact that the power settings > are switching the eth card off. Makes sense. BTW, I see a similar problem on my laptop at home (Leap 42.3 still). I also get the error message Invalid MIT-MAGIC-COOKIE-1 key but X applications can still open the display ...
(In reply to Stefan Dirsch from comment #11) > (In reply to Kacper Pluta from comment #10) > > (In reply to Stefan Dirsch from comment #9) > > > Hmm. No idea why hostname result changes after unlocking the screen. > > > > I think this is not unlocking/locking but the fact that the power settings > > are switching the eth card off. > > Makes sense. BTW, I see a similar problem on my laptop at home (Leap 42.3 > still). I also get the error message > > Invalid MIT-MAGIC-COOKIE-1 key > > but X applications can still open the display ... So far I only see flatpak applications as being affected. I will try to test more later on.
> > Makes sense. BTW, I see a similar problem on my laptop at home (Leap 42.3 > > still). I also get the error message > > > > Invalid MIT-MAGIC-COOKIE-1 key > > > > but X applications can still open the display ... > > So far I only see flatpak applications as being affected. I will try to test > more later on. Try running vim in an xterm window.
(In reply to Michael Hirmke from comment #13) > > > Makes sense. BTW, I see a similar problem on my laptop at home (Leap 42.3 > > > still). I also get the error message > > > > > > Invalid MIT-MAGIC-COOKIE-1 key > > > > > > but X applications can still open the display ... > > > > So far I only see flatpak applications as being affected. I will try to test > > more later on. > > Try running vim in an xterm window. So: nvim, and other X11 programs I've tried work. But flatpak and snap programs have problems. See: flatpak run com.slack.Slack/x86_64/stable Gtk-Message: 08:45:20.580: Failed to load module "canberra-gtk-module" Invalid MIT-MAGIC-COOKIE-1 key (slack:2): Gtk-WARNING **: 08:45:20.580: cannot open display: :99.0 snap run meshlab Invalid MIT-MAGIC-COOKIE-1 keyQXcbConnection: Could not connect to display :0 fish: “snap run meshlab” terminated by signal SIGABRT (Abort) To reproduce this issue I just need to suspend the machine and try to run something from flatpak or snap.
Ok. Couldn't find a snap package for openSUSE, but one for flatpak. I was able to add a flatpak repository of https://flathub.org/home and installed Slack from this repository via flatpak install flathub com.slack.Slack Then I ran flatpak run com.slack.Slack/x86_64/stable Unfortunately the "Sign in" Button does nothing ... Anyway, flatpak using a DISPLAY ":99" sounds a bit weird to me. Maybe they're using a virtual Xserver somehow. Also I don't know how to investigate such a userspace sandbox. Can I chroot into this somehow? No idea. These are my first steps using flatpak ... IMHO somebody with a clue about flatpak/snap should investigate this ... Adding developers lately touching the flatpak package. Maybe they are interested into this issue.
(In reply to Stefan Dirsch from comment #15) > Ok. Couldn't find a snap package for openSUSE, but one for flatpak. I was > able to add a flatpak repository of https://flathub.org/home and installed > Slack from this repository via > > flatpak install flathub com.slack.Slack > > Then I ran > > flatpak run com.slack.Slack/x86_64/stable > > Unfortunately the "Sign in" Button does nothing ... > > Anyway, flatpak using a DISPLAY ":99" sounds a bit weird to me. Maybe > they're using a virtual Xserver somehow. Also I don't know how to > investigate such a userspace sandbox. Can I chroot into this somehow? No > idea. These are my first steps using flatpak ... > > IMHO somebody with a clue about flatpak/snap should investigate this ... > > Adding developers lately touching the flatpak package. Maybe they are > interested into this issue. Maybe this github issue is related: https://github.com/flatpak/flatpak/issues/1821
(In reply to Kacper Pluta from comment #16) > Maybe this github issue is related: > https://github.com/flatpak/flatpak/issues/1821 Yes, this looks indeed related.
What's the output of echo $XAUTHLOCALHOSTNAME If the output of 'echo $XAUTHLOCALHOSTNAME' is empty, do an 'export XAUTHLOCALHOSTNAME=`hostname` before you lock your screen and see if this makes a difference. I'm afraid one would need the $XAUTHLOCALHOSTNAME patches of our libxcb inside of the libxcb shipped with flatpak/snap sandbox packages ...
(In reply to Stefan Dirsch from comment #19) > What's the output of > > echo $XAUTHLOCALHOSTNAME > > If the output of 'echo $XAUTHLOCALHOSTNAME' is empty, do an 'export > XAUTHLOCALHOSTNAME=`hostname` before you lock your screen > and see if this makes a difference. > > I'm afraid one would need the $XAUTHLOCALHOSTNAME patches of our libxcb > inside of the libxcb shipped with flatpak/snap sandbox packages ... The result of echo $XAUTHLOCALHOSTNAME is the same before and after the problem, i.e., PC-CGGC-KACPERP.CS.Technion.ac.il. Best, Kacper
Ok.
There have been some updates on upstream issue tracker meanwhile, which might be useful. https://github.com/flatpak/flatpak/issues/1821
Looks like flatpak is maintained in GNOME:Factory project, so let's reassign to GNOME component.