On Thu 31 Mar 2022 at 07:30:14 (-0400), Greg Wooledge wrote: > On Wed, Mar 30, 2022 at 10:27:25PM -0700, Larry Doolittle wrote: > > 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. > > Huh. That is interesting, and confusing. Because at work, I have the > same setup as you -- 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. > > That bug report contains the clause "my .Xauthority file contains a line > like this" which is also interesting. Mine is not a text file. When I > view it in less, I'm warned that it's a binary file. The file does not > contain "lines" at all (looks like a mixture of text and binary data), > and nothing that looks like "wooledg:0". A few "wooledg", but none with > the ":0" attached.
We can probably assume that the reporter listed it with xauth. Here's mine: $ xauth -f .Xauthority list HOST/unix:0 MIT-MAGIC-COOKIE-1 11223344556677889900aabbccddeeff HOST.corp:0 MIT-MAGIC-COOKIE-1 11223344556677889900aabbccddeeff HOST/unix:15 MIT-MAGIC-COOKIE-1 234567890abcdef1234567890abcdef1 HOST/unix:16 MIT-MAGIC-COOKIE-1 134567890abcdef1234567890abcdef2 HOST/unix:17 MIT-MAGIC-COOKIE-1 124567890abcdef1234567890abcdef3 HOST/unix:18 MIT-MAGIC-COOKIE-1 123567890abcdef1234567890abcdef4 HOST/unix:14 MIT-MAGIC-COOKIE-1 123467890abcdef1234567890abcdef5 HOST/unix:12 MIT-MAGIC-COOKIE-1 123457890abcdef1234567890abcdef6 HOST/unix:13 MIT-MAGIC-COOKIE-1 123456890abcdef1234567890abcdef7 HOST/unix:11 MIT-MAGIC-COOKIE-1 123456790abcdef1234567890abcdef8 HOST/unix:10 MIT-MAGIC-COOKIE-1 123456780abcdef1234567890abcdef9 $ ls -l .Xauthority -rw------- 1 AUSER AUSER 548 Mar 29 10:57 .Xauthority $ … where "corp" is my local domain name, and the rest is obfuscated. I also own a file in /tmp: $ xauth -f /tmp/serverauth.randmchars list HOST/unix:0 MIT-MAGIC-COOKIE-1 123456789abcdef1234567890abcdef0 HOST/unix:1 MIT-MAGIC-COOKIE-1 11223344556677889900aabbccddeeff HOST/unix:2 MIT-MAGIC-COOKIE-1 11223344556677889900aabbccddeeff $ ls -l /tmp/serverauth.randmchars -rw------- 1 AUSER AUSER 147 Mar 31 08:39 /tmp/serverauth.randmchars $ … whose timestamp corresponds with when I booted this machine and started X. (I can't match its first entry with anything else.) > So, there are definitely a few more variables involved in this one. I > don't know why it works for some people (e.g. me) and not others. I don't > know the format of the ~/.Xauthority file, or why it varies across > different Debian systems, or different login accounts. I'm running a browser as a different local user, displayed on my X. Their .Xauthority has an entry identical to the first entry above, along with some different ones, and their file modification timestamp is two hours later. It'll be a couple of decades since I looked at what this all means. I wrote a script that was designed to minimise retyping passwords (pre- key authentication) when I connected and reconnected between machines that were running Xservers. I will say that I've never seen an entry as simple as HOST:0 … >From the above, it might correspond to a host with no domain name. Grasping at straws, I would check my /etc/hosts and /etc/hostname were conformant, and that I had a domain name (like .corp). Exim used to (does still?) complain about the lack of a domain name, but it still performed. I don't know whether X has changed in this regard. I wouldn't expect it to affect ordinary sockets. (I would also have thought others would be complaining.) Disclaimers: this particular machine is still running buster. I don't run a DM (and I don't know what a DCOPserver is). Cheers, David.
