Bug 1137491 - flatpak/snap: "Invalid MIT-MAGIC-COOKIE-1 key" after resume (network/hostname changes?)
flatpak/snap: "Invalid MIT-MAGIC-COOKIE-1 key" after resume (network/hostname...
Status: IN_PROGRESS
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: GNOME
Leap 15.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-06-06 11:40 UTC by Kacper Pluta
Modified: 2020-08-25 10:38 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper Pluta 2019-06-06 11:40:29 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.
Comment 1 Kacper Pluta 2019-06-06 11:41:09 UTC
It looks like mostly/only(?) flatpack programs are affected.
Comment 2 Stefan Dirsch 2019-06-06 13:52:12 UTC
(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?
Comment 3 Kacper Pluta 2019-06-06 13:57:35 UTC
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.
Comment 4 Stefan Dirsch 2019-06-06 14:07:46 UTC
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 ...
Comment 5 Michael Hirmke 2019-06-06 18:40:42 UTC
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.
-------------------------------------------------------------------------
Comment 6 Stefan Dirsch 2019-06-07 09:59:49 UTC
@Michael Hirmke 
Sounds interesting! So it would be good to see also the output of

  hostname -A

before and after locking/unlocking the screen.
Comment 7 Michael Hirmke 2019-06-07 14:05:16 UTC
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.
Comment 8 Kacper Pluta 2019-06-10 07:49:09 UTC
(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.
Comment 9 Stefan Dirsch 2019-06-10 11:27:31 UTC
Hmm. No idea why hostname result changes after unlocking the screen.
Comment 10 Kacper Pluta 2019-06-10 11:53:15 UTC
(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.
Comment 11 Stefan Dirsch 2019-06-11 13:56:36 UTC
(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 ...
Comment 12 Kacper Pluta 2019-06-11 13:59:18 UTC
(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.
Comment 13 Michael Hirmke 2019-06-11 20:56:30 UTC
> > 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.
Comment 14 Kacper Pluta 2019-06-12 05:49:50 UTC
(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.
Comment 15 Stefan Dirsch 2019-06-12 10:41:46 UTC
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.
Comment 16 Kacper Pluta 2019-06-12 10:45:29 UTC
(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
Comment 17 Stefan Dirsch 2019-06-12 10:52:55 UTC
(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.
Comment 19 Stefan Dirsch 2019-06-12 11:54:21 UTC
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 ...
Comment 20 Kacper Pluta 2019-06-20 07:11:57 UTC
(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
Comment 21 Stefan Dirsch 2019-06-20 08:12:07 UTC
Ok.
Comment 22 Stefan Dirsch 2019-08-23 14:47:12 UTC
There have been some updates on upstream issue tracker meanwhile, which might be useful.

https://github.com/flatpak/flatpak/issues/1821
Comment 23 Stefan Dirsch 2020-02-27 10:37:27 UTC
Looks like flatpak is maintained in GNOME:Factory project, so let's reassign to GNOME component.