> xauth list localhost/unix:0 MIT-MAGIC-COOKIE-1 f55ec1b1ce3540e5f49572f8556a7fff > xhost access control enabled, only authorized clients can connect INET:localhost INET6:localhost SI:localuser:root SI:localuser:elm > sudo ps ax| grep Xorg [sudo] Passwort für elm: 5308 tty1 Ssl+ 20:49 /usr/libexec/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch There seem to be some issues about the xauth authorization tokens present under Mageia 8: First xhost lists INET:localhost and INET6:localhost which would allow something like DISPLAY=localhost:0. This is inconsistent with -nolisten tcp. Effect is that there are two xhost entries pretending X-connections would be possible over tcp/localhost while they are not (because of the command line Xorg was started with) Second and more effectively the xauth token should not be issued on localhost. It requires the transient hostname (sys76darp) rather the static hostname (localhost): > hostnamectl Static hostname: localhost Transient hostname: sys76darp Icon name: computer-laptop Chassis: laptop Machine ID: 10da4af917104449ae692a41fc9a656e Boot ID: f1166609753f4d50902b8ac42c7dc874 Operating System: Mageia 8 Kernel: Linux 5.15.82-desktop-1.mga8 Architecture: x86-64 > hostname sys76darp If I change the user from elm to bel, taking the xauth token for localhost with me then it can not connect to the X-server and run no GUI-program. If you want X-connections for other users you need an xhost +SI:localuser:bel in this case or generate an xauth token like (with 'xauth generate . :0'): /> xauth list localhost/unix:0 MIT-MAGIC-COOKIE-1 f55ec1b1ce3540e5f49572f8556a7fff sys76darp/unix:0 MIT-MAGIC-COOKIE-1 47f1ae9474f2abbd255f5ed8344ef39f The following xhost tokens are only necessary because the xauth token has a wrong hostname part: SI:localuser:root SI:localuser:elm On my Mageia 9 installation both the static and transient hostname are set to localhost so that this bug can not be discovered. Also it is a question of me if /etc/hostname and the $HOSTNAME environment variable shouldn´t refer to the transient hostname sys76darp rather than the static hostname localhost.
Thanks for this bug! It has made me harden the xchroot program: https://www.elstel.org/ViewRSS.php?guid=7470&lang=en#7470
I have looked at the /etc/hostname in Debian Bullseye and since it defaults to sys76darp rather than localhost this may be the location where the wrong xauth token comes from.
Have noted M9 SRPM, rather than M8. Doubt that the problem has changed. (In reply to Elmar Stellnberger from comment #1) > Thanks for this bug! It has made me harden the xchroot program: I can find no reference to xchroot in our repos. BTAIM Assigning this globally. The Debian comparison makes this worth investigating.
Source RPM: (none) => xauth-1.1.2-1.mga9.src.rpmAssignee: bugsquad => pkg-bugs
I once wanted to package xchroot for Mageia: Bug 25887. Packages can be found here, though: https://www.elstel.org/software/external-repositories.html.en
$ hostnamectl Static hostname: x3.hodgins.homeip.net Icon name: computer-desktop Chassis: desktop Machine ID: 924899bd8f7d45e5835e73a67b2f2aed Boot ID: 01d7129686a24a2b83a2732cf36aba20 Operating System: Mageia 8 Kernel: Linux 5.15.88-server-1.mga8 Architecture: x86-64 The transient hostname is not guaranteed to exist. We've had problems with xauth in the past that seem to have been resolved. Unless there is very good reason, with backing from xorg upstream such a change is very risky.
CC: (none) => davidwhodgins
My question would be how the hostname can be set under Mageia (with mcc?) as well as at install time. I haven't tried yet to write /etc/hostname and whether that would resolve the issue. Localhost doesn't seem to be a good candidate for the static hostname and yet it is localhost on both Mageia installations I have.
Mageia sets the basic static hostname to localhost (as each system administrator has other needs for his network). It is the task of a system administrator to set a proper static host name for his machines in his network dependend on his needs. If the administrator failed to set a static hostname and there are several machines with "localhost" in a network, the transient hostname get set by a kernel service to identify the machines (until next reboot, as transient hostnames don't survive a reboot). Mageia offers different ways to set a hostname. The commonly used way for all linux distributions is to use the command "hostnamectl set-hostname new-hostname" In case you need more informations about hostnamectl, see man-pages. There is also a graphical way via MCC. If you setup a new connection you can specify the hostname. This is also described in the official Mageia MCC documentation. https://doc.mageia.org/mcc/8/en/content/mcc-network.html#d4e1613
No, the transient hostname didn´t get set on boot automatically. Sys76 stands for the producer of my notebook which is System 76 and Darp stands for Darter Pro the notebook model I have, thus hostname shall be sys76darp as under Debian Bullseye. If I set the environment variable HOSTNAME then it only tells about a static hostname, namely sys76darp. Very likely I have entered this hostname on install time. Finally I am sure not to have changed it afterwards. As said, I have written the /etc/hostname file and will see whether the environment variable gets fetched from there on the next reboot.
A properly configured system has no (visible) transient hostname. Only a static one. This can be seen in Dave's output. That is also the reason why xauth reffers to the static hostname. If you have set a static hostname, the transient one is the same but it won't show up in the "$ hostnamectl" command. The reason why transient hostnames exist is: - you can change the transient hostname whilst the system is running and it wont survive a reboot. This is good for testing purposes in a network - If the administrator failed to properly configure his network and several machines with the static hostname "localhost" exists, the kernel service (or DHCP/mDNS servers) gives each machine a transient hostname to identify the machines. And don't compare apples with peaches. As we don't know how you have setup your Debian machine (and how Debian handles static/transient setup whilst installation) you can't compare it with the Mageia output. The only thing what can be seen on your several outputs is: - you failed to give your machine a static hostname - your machine got a transient hostname (by mDNS, DHCP or Kernel service) - xauth cookie worked as per design as for the identification the static hostname is important Something to read https://www.redhat.com/sysadmin/set-hostname-linux
I know all of this including the hostnamectl command which I have prsented here first, not you. I am reporting an error because this machine seems misconfigured. Your job would be to find out why with me.
(In reply to Elmar Stellnberger from comment #10) > I am reporting an error because this machine seems > misconfigured. Your job would be to find out why with me. You did not set a static hostname whilst installation or setup of your network connection. End.
What I did or did not will best be known by me. Where do you think then, the sys76darp name does stem from? I have reported this because other machines running Mageia could have been affected by a similar issue.
Since you're using Bugzilla again for basic further education, I'll leave it to Dave or Lewis.... There is enough information about static, transient and pretty hostnames and how they are applied. The behaviour you criticise, that the xauth cookie uses the static hostname, is standard compliant. This is not a bug but once again a fundamental understanding problem on your part...
I didn´t criticise that.
The bug summary "Mageia uses static hostname instead of transient hostname for xauth cookie" is based on the assumption xauth should use the transient hostname. The transient hostname is only generated if the system doesn't already have a proper static hostname, and can be generated in multiple ways. It may or may not get the same transient hostname on a reboot. It should not be used for xauth, so closing as invalid. The proper way to avoid the problem is to specify a valid hostname when configuring the network interface.
Status: NEW => RESOLVEDResolution: (none) => INVALID
To be more specific: It should use the same hostname for generating the cookie as for using it. Basically this should be provided by the mechanism running Xorg unless sethostname is called somewhere after starting the X-server, I´d suppose.