Re: startx xauth fails after upgrade to Bullseye 11.3
> my workstation's hostname is the same as my login > username, which is (obviously) also the name of my home directory. > And yet, I've never seen this problem before. > So, there are definitely a few more variables involved in this one. To reproduce, run xauth list $(hostname -f):0 from a directory that has a file or directory with the name of the workstation. Demo: guest@redacted:~/empty$ ls guest@redacted:~/empty$ xauth list $(hostname -f):0 redacted.localdomain:0 MIT-MAGIC-COOKIE-1 d41d8cd98f00b204e9800998ecf8427e guest@redacted:~/empty$ touch $(hostname) guest@redacted:~/empty$ xauth list $(hostname -f):0 Segmentation fault guest@redacted:~/empty$ ls -li ~/.Xauthority-* 57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-c 57941079 -rw--- 2 guest guest 0 Mar 31 13:09 /home/guest/.Xauthority-l guest@redacted:~/empty$ The segfault has been addressed in upstream xauth-1.1.1, which is good! Those changes are incomplete and it still gives a wrong/confusing answer when faced with this accidental name collision. I have a tested patch that I'll write up and add to the 889720 report. - Larry
Re: startx xauth fails after upgrade to Bullseye 11.3
I seem to have rediscovered Debian bug 889720 xauth crashes when directory name matches host name https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720 (Feb 2018) So, nothing to do with the Bullseye upgrade. I must have created that directory-matching-hostname in the process of setting up for the upgrade. - Larry
Re: startx xauth fails after upgrade to Bullseye 11.3
Felix - Felix Miata wrote: > Is the problem avoided if you login via a display manager (gdm, sddm, lightdm, > etc.) instead of using startx? Beats me. I don't have any software like that installed. Would they run xauth before or after cd'ing to my home directory? - Larry P.S. Sorry about breaking threading; I can only read this list via the web.
Re: startx xauth fails after upgrade to Bullseye 11.3
Esteemed Debian experts and maintainers - On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote: > On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote: > > I just upgraded my first machine from 11.2 to 11.3. > > xauth fails in the context of startx. > Workaround: create an empty directory, cd to that, and then startx. > Something about running startx (and therefore xauth) in my home > directory has it very confused. The key command is xauth list $(hostname -f):0 When run in my home directory, it yields a Segmentation fault, and leaves behind two zero-length lock files .Xauthority-l .Xauthority-c that are hard-linked together. I have to remove those files before continuing. When run in an empty subdirectory, that xauth command (correctly) prints one line with an MIT-MAGIC-COOKIE-1, and does not segfault. In the context of /usr/bin/startx (xinit-1.4.0-1), this fault shows up in line 199-200 authcookie=`xauth list "$displayname" \ | sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null; and the lock files left behind prevent the following xauth calls from functioning. I can run xauth (xauth-1:1.1-1) under gdb, but until and unless I recompile it with debugging symbols, the result is not so helpful: Program received signal SIGSEGV, Segmentation fault. __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301 301 ../sysdeps/x86_64/multiarch/strcpy-avx2.S: No such file or directory. (gdb) bt #0 __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301 #1 0x8cc3 in ?? () #2 0x9c8c in ?? () #3 0xa53d in ?? () #4 0xaa1e in ?? () #5 0x8634 in ?? () #6 0x77ca0d0a in __libc_start_main (main=0x8480, argc=3, argv=0x7fffe378, init=, fini=, rtld_fini=, stack_end=0x7fffe368) at ../csu/libc-start.c:308 #7 0x870a in ?? () (gdb) This behavior started when I upgraded to Bullseye 11.3 from 11.2. Until I understand the fault and its trigger better, I can't guarantee that wasn't a coincidence. The xauth segfault is definitely real and a problem for me. - Larry
Re: startx xauth fails after upgrade to Bullseye 11.3
Esteemed Debian experts and maintainers - On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote: > I just upgraded my first machine from 11.2 to 11.3. > xauth fails in the context of startx. > Message is > xauth: timeout in locking authority file /home/[redacted]/.Xauthority > both in the startx console, and if I run "xauth list" > in the resulting X session. Workaround: create an empty directory, cd to that, and then startx. Something about running startx (and therefore xauth) in my home directory has it very confused. It leaves behind extra files (hard-linked to each other): .Xauthority-c and .Xauthority-l. - Larry
startx xauth fails after upgrade to Bullseye 11.3
Esteemed Debian experts and maintainers - I just upgraded my first machine from 11.2 to 11.3. xauth fails in the context of startx. Message is xauth: timeout in locking authority file /home/[redacted]/.Xauthority both in the startx console, and if I run "xauth list" in the resulting X session. It's an annoyance that X takes longer to start. I'm pretty sure my X security is broken, too. E.g., "ssh -X foo" gives a timeout and fallback. I tried downgrading each of server-xorg-video-intel and linux-image-amd64, and neither by itself fixed it. Googling for the problem, the standard questions are what my home directory and .Xauthority permissions are. Sigh. drwxr-xr-x and -rw---. That's not it. I was able to capture output of startx, running it as "sh -x /usr/bin/startx". The relevant section seems to be + /usr/bin/mcookie + mcookie=31343d9e22148031aa3a7b27090d2090 + test x31343d9e22148031aa3a7b27090d2090 = x + dummy=0 + mktemp --tmpdir serverauth.XX + xserverauthfile=/tmp/serverauth.6wEy4jJlBy + trap rm -f '/tmp/serverauth.6wEy4jJlBy' HUP INT QUIT ILL TRAP KILL BUS TERM + xauth -q -f /tmp/serverauth.6wEy4jJlBy + serverargs= vt1 -keeptty -auth /tmp/serverauth.6wEy4jJlBy + authcookie= + [ z = z ] + xauth -q xauth: file /home/[redacted]/.Xauthority does not exist + removelist=:0 + authcookie= + [ z = z ] + xauth -q xauth: timeout in locking authority file /home/[redacted]/.Xauthority + removelist=menace.localdomain:0 :0 (I've tried both removing and not removing .Xauthority* files) Huh. I just tried running startx as a different username. Works fine! WTF? I've never seen anything like this in over a decade of Debian usage. - Larry
