I do not know if this is a bug in xdm, xserver-xfree86, libx11-6
or even in the example program. But when I exchange the execl
in the program given below with a call to main(), this error
does not happen, so this seems to have at least something todo
with libx11-6
Hochachtungsvoll,
Bernhard R. Link
brl@laptop:~/xtest$ xauth list
192.168.2.75:0 MIT-MAGIC-COOKIE-1 e70163149b4e564dd7ec1a22cdc33bf4
laptop/unix:0 MIT-MAGIC-COOKIE-1 e70163149b4e564dd7ec1a22cdc33bf4
192.168.2.75:0 XDM-AUTHORIZATION-1 edb4ac652e525c5100d4085ba3696f4b
laptop/unix:0 XDM-AUTHORIZATION-1 edb4ac652e525c5100d4085ba3696f4b
brl@laptop:~/xtest$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <X11/Xlib.h>
Display *dpy;
int main() {
dpy = XOpenDisplay(":0");
if (dpy == NULL) {
fprintf(stderr, "cannot open display :0\n");
exit(1);
}
fprintf(stderr, "opened display :0\n");
XCloseDisplay(dpy);
execl("./test","./test", NULL);
exit(0);
}
brl@laptop:~/xtest$ make
gcc -g -O0 -Wall -L/usr/X11R6/lib -lX11 test.c -o test
brl@laptop:~/xtest$ ./test
opened display :0
Xlib: connection to ":0.0" refused by server
Xlib: XDM authorization key matches an existing client!
cannot open display :0
brl@laptop:~/xtest$ echo $?
1
This "bug" seems to be caused by the following code
in xfree86-4.3.0.dfsg.1/xc/lib/X11/ConnDis:1062
-------------------------------------------------
/*
* We don't use the sockaddr_un for this encoding.
* Instead, we create a sockaddr_in filled with
* a decreasing counter for the address, and the
* pid for the port.
*/
static unsigned long unix_addr = 0xFFFFFFFF;
unsigned long the_addr;
unsigned short the_port;
_XLockMutex(_Xglobal_lock);
the_addr = unix_addr--;
_XUnlockMutex(_Xglobal_lock);
the_port = getpid ();
-------------------------------------------------
Is this a bug in libX11, a bug in Xserver for insisting
uniqueness with such addresses, or shall I report
a bug against 9menu, which execs other programs
without forking?
Hochachtungsvoll,
Bernhard R. Link
Hi BernhardHi, About 2 years ago, you reported a bug to the Debian BTS regarding XOpenDisplay failing because the XDM auth key matched an existing client. I tried to reproduce with your testcase, but I couldn't. The relevant source code did not change a lot, but did changed a little bit. Did you reproduce this problem recently? If not, I will close this bug in the next weeks. Thanks, Brice
* Brice Goglin <Brice.Goglin@ens-lyon.org> [070212 20:58]: Perhaps this bug should be reassigned to the xserver code responsible for it (Have not looked yet since the split, so I do not know where it ended up in). Hochachtungsvoll, Bernhard R. Link The bug can be worked around quite well by adding DisplayManager*authName: MIT-MAGIC-COOKIE-1 to /etc/X11/xdm/xdm-config, so that no XDM-AUTHORIZATION-1 keys are generated. I do not even know if there are other dms but xdm that use XDM-AUTHORIZATION-1 cookies at all.
Bernhard R. Link wrote: Could you please describe what I exactly need to do to reproduce? Thanks, Brice
* Brice Goglin <Brice.Goglin@ens-lyon.org> [070214 01:03]: I'm assuming you just need to run the program in the example (which only works when your display is :0 and the compiled program is called ./test, but that is easy to change), when there is a XDM-AUTHORIZATION-1 cookie for it in your .Xauthority file (loggin in with xdm should suffice, unless xdm-config now contains authName by default, but AFAIK it does not). There is a bit of timing involved, so a local X server would be best, but as the example tries until it fails, it should be visible nevertheless. I don't know if it took longer on slower computers I no longer have available, but on current ones it always triggers for me after the first exec. Hochachtungsvoll, Bernhard R. Link
Hi Brice, hi Joey,
(simultaneously replying to both bugs because the problem in
the underlying C libraries seems to be identical)
I can provide a short bug summary, maybe it's helpful.
For PF_UNIX connections with an XDM-AUTHORIZATION-1 key, the
client (libx11/libxcb) constructs its 24-byte auth message (which the
server expects to be unique) from the following dynamic parts:
* the time (second granularity)
* the caller's pid
* a nonce
This nonce is generated in libxcb-1.1:src/xcb_auth.c:next_nonce()
by decrementing a function-local persistent (static) counter
variable (the code did not change much compared to the non-xcb
fragment that Bernhard posted to #292388 in 2005):
] static int next_nonce(void)
] {
] static int nonce = 0;
] static pthread_mutex_t nonce_mutex = PTHREAD_MUTEX_INITIALIZER;
] int ret;
] pthread_mutex_lock(&nonce_mutex);
] ret = nonce++;
] pthread_mutex_unlock(&nonce_mutex);
] return ret;
] }
Thus any unloading of the library will reset the nonce, and doing so
without changing the pid will trigger the bug. One possibility is
execve(), as Bernhard has demonstrated - SDL seems to employ the
other one (un- and reloading libxcb without exec()ing)... on my box,
enigma (among several other SDL games, e.g. kobodeluxe - but let's
stick to enigma for this example) reliably activates the bug:
] jcn@hejre:~$ /usr/games/enigma
] XDM authorization key matches an existing client!Couldn't initialize SDL: Couldn't open X11 display
] jcn@hejre:~$ ldd /usr/games/enigma | grep lib[SXx]
] libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7e64000)
] libSDL_image-1.2.so.0 => /usr/lib/libSDL_image-1.2.so.0 (0xb7e49000)
] libSDL_mixer-1.2.so.0 => /usr/lib/libSDL_mixer-1.2.so.0 (0xb7de6000)
] libSDL_ttf-2.0.so.0 => /usr/lib/libSDL_ttf-2.0.so.0 (0xb7de1000)
] libxerces-c.so.27 => /usr/lib/libxerces-c.so.27 (0xb79f5000)
] jcn@hejre:~$ strace -eopen,socket,connect /usr/games/enigma
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libz.so.1", O_RDONLY) = 4
] open("/usr/lib/libzipios.so.0", O_RDONLY) = 4
] open("/usr/lib/libSDL-1.2.so.0", O_RDONLY) = 4
] open("/usr/lib/libSDL_image-1.2.so.0", O_RDONLY) = 4
] open("/usr/lib/libSDL_mixer-1.2.so.0", O_RDONLY) = 4
] open("/usr/lib/libSDL_ttf-2.0.so.0", O_RDONLY) = 4
] open("/usr/lib/libxerces-c.so.27", O_RDONLY) = 4
] open("/usr/lib/libpng12.so.0", O_RDONLY) = 4
] open("/lib/libdl.so.2", O_RDONLY) = 4
] open("/usr/lib/libstdc++.so.6", O_RDONLY) = 4
] open("/lib/libm.so.6", O_RDONLY) = 4
] open("/lib/libgcc_s.so.1", O_RDONLY) = 4
] open("/lib/libc.so.6", O_RDONLY) = 4
] open("/lib/libpthread.so.0", O_RDONLY) = 4
] open("/usr/lib/libasound.so.2", O_RDONLY) = 4
] open("/usr/lib/libdirectfb-1.0.so.0", O_RDONLY) = 4
] open("/usr/lib/libfusion-1.0.so.0", O_RDONLY) = 4
] open("/usr/lib/libdirect-1.0.so.0", O_RDONLY) = 4
] open("/usr/lib/libvga.so.1", O_RDONLY) = 4
] open("/usr/lib/libjpeg.so.62", O_RDONLY) = 4
] open("/usr/lib/libtiff.so.4", O_RDONLY) = 4
] open("/usr/lib/libmikmod.so.2", O_RDONLY) = 4
] open("/usr/lib/libfreetype.so.6", O_RDONLY) = 4
] open("/usr/lib/libicuuc.so.38", O_RDONLY) = 4
] open("/usr/lib/libicudata.so.38", O_RDONLY) = 4
] open("/usr/share/games/enigma/compat.lua", O_RDONLY) = 4
] open("/usr/share/games/enigma/startup.lua", O_RDONLY) = 4
] open("/usr/share/games/enigma/enigma_conf.lua", O_RDONLY) = 4
] open("/usr/share/games/enigma/enigma_conf.lua2", O_RDONLY) = -1 ENOENT (No such file or directory)
] open("/home/jcn/.enigmarc", O_RDONLY) = 4
] open("/home/jcn/.enigmarc2", O_RDONLY) = 4
] open("/home/jcn/.enigmarc.xml", O_RDONLY) = 4
] open("/usr/share/games/enigma/schemas/preferences.xsd", O_RDONLY) = 5
] open("/usr/share/games/enigma/schemas/enigmarc.xml", O_RDONLY) = 4
] open("/usr/share/games/enigma/schemas/preferences.xsd", O_RDONLY) = 5
] open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 4
enigma opens an X connection for the first time, pulling the Xlibs in...
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libX11.so.6", O_RDONLY) = 4
] open("/usr/lib/libxcb-xlib.so.0", O_RDONLY) = 4
] open("/usr/lib/libxcb.so.1", O_RDONLY) = 4
] open("/usr/lib/libXau.so.6", O_RDONLY) = 4
] open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXext.so.6", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXrender.so.1", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXrandr.so.2", O_RDONLY) = 4
] open("/usr/share/locale/locale.alias", O_RDONLY) = 4
] open("/usr/share/locale/en_IE@euro/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
] open("/usr/share/locale/en@euro/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
] open("/usr/share/locale/en_IE/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
] open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
] socket(PF_FILE, SOCK_STREAM, 0) = 4
] connect(4, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0
] open("/home/jcn/.Xauthority", O_RDONLY) = 5
And immediately after that, all X libraries are loaded again...
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libX11.so.6", O_RDONLY) = 4
] open("/usr/lib/libxcb-xlib.so.0", O_RDONLY) = 4
] open("/usr/lib/libxcb.so.1", O_RDONLY) = 4
] open("/usr/lib/libXau.so.6", O_RDONLY) = 4
] open("/usr/lib/libXdmcp.so.6", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXext.so.6", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXrender.so.1", O_RDONLY) = 4
] open("/etc/ld.so.cache", O_RDONLY) = 4
] open("/usr/lib/libXrandr.so.2", O_RDONLY) = 4
] socket(PF_FILE, SOCK_STREAM, 0) = 4
] connect(4, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0
] open("/home/jcn/.Xauthority", O_RDONLY) = 5
] XDM authorization key matches an existing client!Couldn't initialize SDL: Couldn't open X11 display
] Process 28648 detached
I assume that python-pygame is doing something similar. I'm neither
python nor SDL expert, so I'm afraid I can't help any further.
Brice, has there been any upstream comment on this? I know that
bug for ages, but could never find much information about it, so
I assumed my box to be a corner case.
Regards,
Jan
* Jan Christoph Nordholz <hesso@pool.math.tu-berlin.de> [080211 00:43]: other DMs are not setting a XDM-AUTHORIZATION-COOKIE[1], so noone sees this problem[2]. I personally tend to think it is a bug in the Xserver. if it gets a new connection with the same data, it should first look if the previous connection has finished. I guess it's just a race condition that it first tries the new connect before realizing the old is gone. Hochachtungsvoll, Bernhard R. Link [1] You can also tell xdm to not set it by adding a DisplayManager*authName: MIT-MAGIC-COOKIE-1 to /etc/X11/xdm/xdm-config Perhaps that would be an sensible default for xdm? I don't think using those cookies gives anysecurity benefit. [2] Only people using xdm and only when using specifiy programs. firefox had it relatively often for some time, but that changed, too.
Hi, yes, I know that only xdm users are affected. On the other hand I couldn't believe that its userbase should be so small, especially in the old days when gnome and kde weren't that shiny... I don't know since how many years I'm experiencing this bug, but it's been quite some time. I haven't looked at that part of the server yet. That would be an elegant solution, although the static-variable-in-solib thing leaves a bad taste as well... I'd really appreciate some input from upstream, but the bugreport at freedesktop.org is empty since Brice created it. Hm, if we want to go that way, we could even start shipping xdm with XDM-AUTH disabled at compile-time - there's a switch for it. Most SDL programs seem to be affected presently - but that may also be due to some recent change in the way SDL handles X11. Regards, Jan
Package: libx11-6 Version: 2:1.1.4-2 Followup-For: Bug #292388 Hello, Since todays update of ,---- | libx11-6 2:1.0.3-7 -> 2:1.1.4-2 | libx11-data 2:1.0.3-7 -> 2:1.1.4-2 `---- I get this ,----[ .xsession-errors ]- | Xsession: X session started for user at Di 10. Jun 09:54:40 CEST 2008 | XDM authorization key matches an existing client! | (x-session-manager:3924): Gtk-WARNING **: cannot open display: :0 `---- too if xdm wants to start Xfce4. With kind regards Dirk
I've been using xdm and qemu for ages w/o problems, but today I began seeing this bug when using qemu. joey@kodama:~>qemu -boot a -fda boot_70.img -fdb root.img XDM authorization key matches an existing client!Could not initialize SDL - exiting ii libx11-6 2:1.1.4-2 X11 client-side library ii qemu 0.9.1-5 fast processor emulator ii xdm 1:1.1.8-1 X display manager I upgraded libx11-6 from version 2:1.0.3-7 on 2006-06-12, and this is probably the first time I've tried to start qemu since then. (Also rebooted recently if it matters.) I see this in Xorg.0.log: AUDIT: Mon Jun 16 15:11:08 2008: 9234 X: client 17 rejected from local host (uid 1000) Auth name: XDM-AUTHORIZATION-1 ID: -1 Since this bug has been open for ages and seems tricky to fix, and there's a simple workaround in the xdm configuration, is there any reason to not apply the workaround in the default config?
severity 292388 important clone 292388 -1 reassign -1 xdm found -1 1:1.1.8-1 retitle -1 xdm:unable to login - XDM authorization key matches an existing client thanks I have got the same problem with xdm, directly after upgrade of libx11-6 from 1.0.3 to 1.1.4 (it is on GNU/kFreeBSD, but it shouldn't matter). The workaround/fix to add DisplayManager*authName: MIT-MAGIC-COOKIE-1 into to /etc/X11/xdm/xdm-config works for me. Petr
reassign 522876 libx11-6 forcemerge 292388 522876 stop Hello, As per #292388 and its clone #486606 (which contains a way to work around it), it seems that the bug is not in SDL but deeper in the X11 layers, and was forwarded to [1]. According to #486606, the authorisation method was disabled in 2008 for libx11 libraries, almost 4 years ago, so I don't think that it's possible to reproduce it anymore. In any case, it works perfectly fine for me (luvcview 0.2.6-6), also with unstable as of today, and amd64 arch. Since the bug is already reported to X11 package and upstream, I don't think that any new action is needed. If somebody can reproduce it and provide more insight, please add info to these bug reports. I am merging it with #292388 because I believe that it belongs in there. Cheers and thanks for the report, and the interest in improving Debian. [1] https://bugs.freedesktop.org/show_bug.cgi?id=10665