Check for root owned files in /home/$USER with

find $HOME ! \( -group $USER -or -user $USER \) -exec ls -al '{}' \;

The files can become root owned if you use su without the --login option,
which can be abbreviated as "su -".

CC: (none) => davidwhodgins

No, all files are owned by my user.
drakconf was called as regular user, which shows the "authenticate as root" dialog.
As stated, it works right after startup for some time, but not after some suspend (some hours).

How is the magic-cookie passed/updated by the root user? Maybe there is some update issue.

That's the most common cause I've seen, though it's been a long time since I've
seen it. What is the output of xauth list both as regular user and as root after
using "su -"? On my system ...
[dave@x3 ~]$ xauth list
x3.hodgins.homeip.net/unix:0  MIT-MAGIC-COOKIE-1  04305ce55d0a9ba708e21b4626b9e6e6
[dave@x3 ~]$ su -
Password: 
[root@x3 ~]# xauth list
x3.hodgins.homeip.net/unix:0  MIT-MAGIC-COOKIE-1  04305ce55d0a9ba708e21b4626b9e6e6

my output is

xauth list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  e0fe5a34914470a8fbcc7c666aa9d4e9
localhost/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591
[marc@localhost ~]$ su -
Passwort: 
-bash-4.4# xauth list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  e0fe5a34914470a8fbcc7c666aa9d4e9

after setting 
xauth add localhost/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591
xauth add localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591

[marc@localhost ~]$ su
Passwort: 
xauth list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591

drakconf/xterm works

So where is the difference between localhost/unix:0 and localhost.localdomain/unix:0 and why are not both updated the same time to the same Cookie?!

My understanding is that it's set by Xorg. Why it sometimes uses localhost
and other times uses localhost.localdomain, I don't know. I always use
my own host names, so don't encounter the problem myself.

I do know the hostname is set in two places. Perhaps they are different on
that system. On my system ...
[root@x3 ~]# cat /etc/hostname
x3.hodgins.homeip.net
[root@x3 ~]# grep HOSTNAME /etc/sysconfig/network
HOSTNAME=x3.hodgins.homeip.net

[root@localhost ~]# cat /etc/hostname
localhost
[root@localhost ~]# grep HOSTNAME /etc/sysconfig/network
[root@localhost ~]# hostname
localhost.localdomain

I'm using networkmanager, since mga network tools don't work very well with e.g. suspend and wlan connections. But I don't see any setting to set/keep hostname.

You can use any text editor to make the two file consistent. That will ensure
the problem doesn't recur. Whether localhost or localhost.localdomain is used
doesn't matter, as long as they are consistent.

after the last suspend both xauth differ again and mcc doesn't start:
[marc@haudraufwienix ~]$ xauth list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591
localhost/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591
[marc@haudraufwienix ~]$ su -
Passwort: 
-bash-4.4# xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  905a2c40ec8d72b1a0f5a8edb090189b
-bash-4.4# 


as you can see xauth of my user is unchanged, but xauth of root user got magically changed.

any ideas what to check and why this happens?

Looks like networkmanager is altering the hostname. When it's set to localhost,
networkmanager is changing it to localhost.localdomain.

In my opinion, it shouldn't, but adding a patch to make it work differently
in Mageia than it does in other distributions is probably not a good idea.

Workaround would be to ensure /etc/hostname file has localhost.localdomain
instead of just localhost.

While the hostname and domain name technically should be considered separate,
it's clear that unlike drakxnet, networkmanager is not making the distinction.

Either we should add a patch to networkmanager to have it set the hostname
to localhost instead of localhost.localdomain, or we should alter the
libdrakx-net code to set the hostname to localhost.localdomain.

Assignee: bugsquad => mageiatools
CC: (none) => olav

you're right localhost.localdomain in /etc/hostname solved it. Added it to /etc/hosts too

I thought it is solved, but unfortunately it is not:

[marc@localhost ~]$ cat /etc/hostname 
localhost.localdomain
[marc@localhost ~]$ hostname
localhost.localdomain
[marc@localhost ~]$ xauth list
localhost/unix:0  MIT-MAGIC-COOKIE-1  b0525838f3a5ebdcec9cc7bb3e37d591
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  d4de44df1ba170ac50dc2675754dc23b
haudraufwienix.fritz.box/unix:0  MIT-MAGIC-COOKIE-1  cc3e42bdd42665e3e47f2f321760fe89
[marc@localhost ~]$ su -
Passwort: 
[root@localhost marc]# xauth list
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  d4de44df1ba170ac50dc2675754dc23b
[root@localhost marc]# drakconf
Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Invalid MIT-MAGIC-COOKIE-1 keyUnable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt


As you can see hostname matches, cookies for this hostname matches, but still xauth refuses to connect - if this helps, this issue was introduced with mga7, in mga6 it worked well (I had posted on this issue some earlier)

At one point Mutter learned how to set the .Xauthority. This because of a difference between GDM running Xorg vs GDM running Wayland.

https://gitlab.gnome.org/GNOME/mutter/-/commit/a8984a81c2e887623d69ec9989ae8a5025f7bd47
https://gitlab.gnome.org/GNOME/mutter/-/issues/643

From the NEWS file it seems this was fixed/added as part of Mutter 3.33.3.

There's also an XDG autostart file to set this manually: /etc/xdg/autostart/gnome-enable-root-gui.desktop

There's also this commit: https://gitlab.gnome.org/GNOME/mutter/-/commit/c35e56196a0955b52e87a808126f09f79bebe731. It has an interesting commit message:
> xwayland: Use g_get_host_name instead of gethostname
>
> Since the xauth file is never going to be changed after it is generated,
> it is safe to use g_get_host_name here.

The following (old) bug report seems related to what is being said here (hostname mismatches):
https://bugzilla.gnome.org/show_bug.cgi?id=688716

Also noticed: https://mail.gnome.org/archives/networkmanager-list/2010-June/msg00135.html, this indicates that there's a method to not use the hostname for validation.

I'm wondering if maybe /etc/xdg/autostart/gnome-enable-root-gui.desktop is changing the magic cookie just after you've started MCC. Could you temporarily move that file to somewhere else? Please tell me if it works after that.

The autostart only runs under GNOME, for both Wayland and Xorg. Are you running GNOME?

The other possibility is that NetworkManager is really updating that file somehow. I couldn't figure out where/how this might be triggered.

no, I'm running LXQT and before LXDE, both showed the same problem.
Maybe I switch back to mate, but not gnome (anymore, since gnome 3).

Could you perhaps do a grep -r xhost /etc ?

It's strange that the old cookie changes. I did notice that I have many magic cookies. I changed the hostname ages ago, I see various with the old hostname, plus various under the new name. There are 14 in total, uptime of 52 days. I actually stopped using this machine as a desktop, though gdm is running.

While grepping I noticed there's an xauth PAM thing. It e.g. activates on "su". It should merge the files. Plus msec might run xhost.

grep -r xhost /etc
/etc/X11/Xsession:if [ -x /usr/bin/xhost ] && [ -x /usr/bin/id ]; then
/etc/X11/Xsession:    xhost +si:localuser:`id -un` >& /dev/null

what is the contents of your pam file?

(stumbled across this whilst searching for another bug report)

You can prevent NM from setting the hostname by appending the line

  hostname-mode=none

to /etc/NetworkManager/NetworkManager.conf.

If that isn't enough, the solution is to run

  xhost +si:localhost:root

each time you start an X session. That's what /etc/xdg/autostart/gnome-enable-root-gui.desktop does.

CC: (none) => mageia

Martin, would it be safe to make it a default for NM installs to have hostname-mode=none?

A better default choice might be hostname-mode=dhcp, which would set the hostname if supplied by the DHCP server, but not attempt the reverse DNS lookup.

However, this problem can occur even when not using NM. For instance, using the 8-rc Live Plasma which still uses the legacy network service, I found that configuring the network using drakconnect was enough to trigger it (bug 28280, comment 13). The proper fix of course is to rewrite the Mageia tools to separate the GUI from the privileged actions, but that's not likely to happen (the manatools project seems to have ground to a halt). So I think we should use the xhost workaround. We already accepted that to get the drakx tools to run in GNOME/Wayland for Mageia 6 and 7.

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED