NetBSD Problem Report #57236

From www@netbsd.org  Fri Feb 17 20:32:38 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 227701A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 17 Feb 2023 20:32:38 +0000 (UTC)
Message-Id: <20230217203237.06A881A923A@mollari.NetBSD.org>
Date: Fri, 17 Feb 2023 20:32:37 +0000 (UTC)
From: m.kozlowski@mini.pw.edu.pl
Reply-To: m.kozlowski@mini.pw.edu.pl
To: gnats-bugs@NetBSD.org
Subject: Gude, 9.8, https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong
X-Send-Pr-Version: www-1.0

>Number:         57236
>Category:       xsrc
>Synopsis:       Gude, 9.8, https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 17 20:35:00 +0000 2023
>Closed-Date:    
>Last-Modified:  Sun Jul 27 16:36:50 +0000 2025
>Originator:     Marek
>Release:        9.3 amd64
>Organization:
>Environment:
NetBSD t400net 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
From a terminal startxfce4 works fine. However I'm unable to login with xdm. The message is:

$ cat .xsession-errors 
/usr/pkg/bin/startxfce4: X server already running on display :0
XDM authorization key matches an existing client!xfce4-session: Cannot open display: .
Type 'xfce4-session --help' for usage.
xterm: fatal IO error 35 (Resource temporarily unavailable) or KillClient on X server ":0"

>How-To-Repeat:
Follow the chapters 9.7 and 9.8 of the Guide
>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: port-amd64-maintainer->gutteridge
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Fri, 17 Feb 2023 20:50:47 +0000
Responsible-Changed-Why:
I'll take this PR.

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Wed, 22 Feb 2023 00:14:05 -0500

 Hello,

 Please try adding the following line to your /etc/X11/xdm/xdm-config
 file:

 DisplayManager*authName:	MIT-MAGIC-COOKIE-1

 Regards,

 Dave

From: Marek Kozlowski <m.kozlowski@mini.pw.edu.pl>
To: <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Thu, 23 Feb 2023 22:01:34 +0100

 :-)

 Thanks! It helped!

 Honestly I'm not quite sure if I know what the problem was and why it 
 helped but now it's fine.

 Best regards,
 Marek

 On 2/22/23 06:15, David H. Gutteridge wrote:
 > The following reply was made to PR pkg/57236; it has been noted by GNATS.
 > 
 > From: "David H. Gutteridge" <david@gutteridge.ca>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: port-amd64/57236 (Gude, 9.8,
 >   https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
 > Date: Wed, 22 Feb 2023 00:14:05 -0500
 > 
 >   Hello,
 >   
 >   Please try adding the following line to your /etc/X11/xdm/xdm-config
 >   file:
 >   
 >   DisplayManager*authName:	MIT-MAGIC-COOKIE-1
 >   
 >   Regards,
 >   
 >   Dave
 >   
 > 

From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57236 CVS commit: htdocs/docs/guide/en
Date: Fri, 24 Feb 2023 15:48:00 +0000

 Module Name:	htdocs
 Committed By:	gutteridge
 Date:		Fri Feb 24 15:48:00 UTC 2023

 Modified Files:
 	htdocs/docs/guide/en: chap-x.xml

 Log Message:
 chap-x.xml: add detail about xdm's default authorization

 Our current distribution of xdm no longer interoperates with various
 modern X applications by default. DisplayManager*authName must be
 overridden to allow only MIT-MAGIC-COOKIE-1 for them to work. This
 commit partly addresses PR 57236 from Marek Kozlowski.


 To generate a diff of this commit:
 cvs rdiff -u -r1.24 -r1.25 htdocs/docs/guide/en/chap-x.xml

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Fri, 24 Feb 2023 11:47:33 -0500

 On Thu, 2023-02-23 at 21:05 +0000, Marek Kozlowski wrote:
 > The following reply was made to PR xsrc/57236; it has been noted by
 > GNATS.
 >=20
 > From: Marek Kozlowski <m.kozlowski@mini.pw.edu.pl>
 > To: <gnats-bugs@netbsd.org>
 > Cc:=20
 > Subject: Re: port-amd64/57236 (Gude, 9.8,
 > =C2=A0https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm=C2=A0is wro=
 ng)
 > Date: Thu, 23 Feb 2023 22:01:34 +0100
 >=20
 > =C2=A0:-)
 > =C2=A0
 > =C2=A0Thanks! It helped!
 > =C2=A0
 > =C2=A0Honestly I'm not quite sure if I know what the problem was and why =
 it
 > =C2=A0helped but now it's fine.

 The issue is basically that as we presently distribute xdm, it won't
 interoperate properly with some modern X applications, because the
 authorization mechanism it defaults to doesn't work. This was surprising
 to me as well (I don't use xdm or any other display manager), as the
 error messages aren't clear here about what's happening. I was able to
 reproduce this myself and test the configuration tweak.

 Other BSDs and Linux distros dealt with this years ago; e.g., FreeBSD
 changed the default in the configuration to be what I suggested, Debian
 changed xdm's compilation settings to fundamentally disable the xdm
 authorization method, etc. I feel NetBSD should do something of the sort
 as well, but that probably requires discussion among developers. So, for
 now, I've adjusted chapter 9.8 in the guide to add this detail.

 Thanks for using Xfce on NetBSD and for reporting this issue.

 Regards,

 Dave

From: Marek Kozlowski <m.kozlowski@mini.pw.edu.pl>
To: <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Fri, 24 Feb 2023 18:26:53 +0100

 :-)

 I'd really appreciate if there was lightdm in future releases. xdm is a 
 bit, let's say... vintage...

 Best regards,
 Marek

 On 2/24/23 17:50, David H. Gutteridge wrote:
 > The following reply was made to PR xsrc/57236; it has been noted by GNATS.
 > 
 > From: "David H. Gutteridge" <david@gutteridge.ca>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: port-amd64/57236 (Gude, 9.8,
 >   https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
 > Date: Fri, 24 Feb 2023 11:47:33 -0500
 > 
 >   On Thu, 2023-02-23 at 21:05 +0000, Marek Kozlowski wrote:
 >   > The following reply was made to PR xsrc/57236; it has been noted by
 >   > GNATS.
 >   >=20
 >   > From: Marek Kozlowski <m.kozlowski@mini.pw.edu.pl>
 >   > To: <gnats-bugs@netbsd.org>
 >   > Cc:=20
 >   > Subject: Re: port-amd64/57236 (Gude, 9.8,
 >   > =C2=A0https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm=C2=A0is wro=
 >   ng)
 >   > Date: Thu, 23 Feb 2023 22:01:34 +0100
 >   >=20
 >   > =C2=A0:-)
 >   > =C2=A0
 >   > =C2=A0Thanks! It helped!
 >   > =C2=A0
 >   > =C2=A0Honestly I'm not quite sure if I know what the problem was and why =
 >   it
 >   > =C2=A0helped but now it's fine.
 >   
 >   The issue is basically that as we presently distribute xdm, it won't
 >   interoperate properly with some modern X applications, because the
 >   authorization mechanism it defaults to doesn't work. This was surprising
 >   to me as well (I don't use xdm or any other display manager), as the
 >   error messages aren't clear here about what's happening. I was able to
 >   reproduce this myself and test the configuration tweak.
 >   
 >   Other BSDs and Linux distros dealt with this years ago; e.g., FreeBSD
 >   changed the default in the configuration to be what I suggested, Debian
 >   changed xdm's compilation settings to fundamentally disable the xdm
 >   authorization method, etc. I feel NetBSD should do something of the sort
 >   as well, but that probably requires discussion among developers. So, for
 >   now, I've adjusted chapter 9.8 in the guide to add this detail.
 >   
 >   Thanks for using Xfce on NetBSD and for reporting this issue.
 >   
 >   Regards,
 >   
 >   Dave
 >   
 > 

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: gutteridge@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, m.kozlowski@mini.pw.edu.pl
Subject: re: port-amd64/57236 (Gude, 9.8, https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Sat, 25 Feb 2023 06:28:15 +1100

 >  The issue is basically that as we presently distribute xdm, it won't
 >  interoperate properly with some modern X applications, because the
 >  authorization mechanism it defaults to doesn't work. This was surprising
 >  to me as well (I don't use xdm or any other display manager), as the
 >  error messages aren't clear here about what's happening. I was able to
 >  reproduce this myself and test the configuration tweak.
 >  
 >  Other BSDs and Linux distros dealt with this years ago; e.g., FreeBSD
 >  changed the default in the configuration to be what I suggested, Debian
 >  changed xdm's compilation settings to fundamentally disable the xdm
 >  authorization method, etc. I feel NetBSD should do something of the sort
 >  as well, but that probably requires discussion among developers. So, for
 >  now, I've adjusted chapter 9.8 in the guide to add this detail.

 i'm confused.  the default should be:

    "XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1"

 so i'm not sure why the xdm-config setting is needed.  or is it
 that "XDM-AUTHORIZATION-1" method doesn't work at all, and it
 can only be "MIT-MAGIC-COOKIE-1"?  this seems to be the default,
 since libXdcmp default to including XdmcpWrap.c, which means
 xdm finds it and enables xdm auth methods.

 anyway, we can fix this i'm sure, but i don't understand what's
 wrong or why the change helps.

 thanks.


 .mrg.

From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Thu, 02 Mar 2023 00:06:55 -0500

 On Fri, 2023-02-24 at 17:30 +0000, Marek Kozlowski wrote:
 > =C2=A0:-)
 > =C2=A0
 > =C2=A0I'd really appreciate if there was lightdm in future releases. xdm =
 is
 > a bit, let's say... vintage...
 >=20

 It's very unlikely we'd ever have lightdm in xbase, as it requires
 glib2, Python, and such. It of course could be placed in pkgsrc proper,
 along with SDDM. (We do have SLiM in pkgsrc, though I can't vouch for
 its current state.) Agreed xdm is probably not the best option here.

 Regards,

 Dave

From: "David H. Gutteridge" <david@gutteridge.ca>
To: matthew green <mrg@eterna.com.au>, gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8,
 https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Thu, 02 Mar 2023 00:18:40 -0500

 On Sat, 2023-02-25 at 06:28 +1100, matthew green wrote:
 > > =C2=A0The issue is basically that as we presently distribute xdm, it
 > > won't
 > > =C2=A0interoperate properly with some modern X applications, because th=
 e
 > > =C2=A0authorization mechanism it defaults to doesn't work. This was
 > > surprising
 > > =C2=A0to me as well (I don't use xdm or any other display manager), as
 > > the
 > > =C2=A0error messages aren't clear here about what's happening. I was ab=
 le
 > > to
 > > =C2=A0reproduce this myself and test the configuration tweak.
 > > =C2=A0
 > > =C2=A0Other BSDs and Linux distros dealt with this years ago; e.g.,
 > > FreeBSD
 > > =C2=A0changed the default in the configuration to be what I suggested,
 > > Debian
 > > =C2=A0changed xdm's compilation settings to fundamentally disable the x=
 dm
 > > =C2=A0authorization method, etc. I feel NetBSD should do something of t=
 he
 > > sort
 > > =C2=A0as well, but that probably requires discussion among developers.
 > > So, for
 > > =C2=A0now, I've adjusted chapter 9.8 in the guide to add this detail.
 >=20
 > i'm confused.=C2=A0 the default should be:
 >=20
 > =C2=A0=C2=A0 "XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1"
 >=20
 > so i'm not sure why the xdm-config setting is needed.=C2=A0 or is it
 > that "XDM-AUTHORIZATION-1" method doesn't work at all, and it
 > can only be "MIT-MAGIC-COOKIE-1"?=C2=A0 this seems to be the default,
 > since libXdcmp default to including XdmcpWrap.c, which means
 > xdm finds it and enables xdm auth methods.

 Yes, that's right, when XDM-AUTHORIZATION-1 is included (first, in the
 default), it is what gets used, and then things can break. The problem
 is that applications can do things like reload X11 libraries after init,
 and this causes the cookie state to get duplicated. The underlying code
 used by many clients (found these days in libxcb) is problematic. It
 uses a function-local static variable to generate a simple nonce for the
 cookie, which can get unintentionally reset, and mixes that with the PID
 and system time to the second for "uniqueness".

 This is 100% reproducible for me with 10.99.2 and Xfce from pkgsrc
 2022Q4. All that needs to be done is to start xdm (from xbase) with the
 default configuration, and set "exec startxfce4" in .xsession. (While it
 is wrong, per upstream, to start xfce4-session directly instead, I also
 tested with that, same result.) In these examples, dbus is not enabled
 before startup. I'm assuming that's how the reporter configured things.

 Having ktraced what's happening to see what goes on with this specific
 example, I see that xfce4-session tries to start a dbus session if one
 isn't already enabled. It does so by calling 'execvp("dbus-launch",...'
 dbus itself (by default in pkgsrc) is linked against X11 libraries,
 including libxcb, like xfce4-session.

 So, when the process starts, it loads libxcb, calculates "PID+nonce=3D0+
 seconds since the epoch" for use by xdm authorization. Then it calls
 execvp(), re-loading libxcb in the process, which resets the nonce to
 0, and the PID is the same, as is the seconds since epoch value. The
 authorization mechanism then sees that the same cookie has been
 generated twice and bombs.

 Since so many downstream consumers of potentially affected software
 long ago worked around this one way or another (or, indeed, stopped
 documenting or recommending anyone use xdm with any DEs), I guess this
 doesn't come up much anymore. There are references in older bug reports
 to non-DE applications like SDL-based games also encountering this
 problem. Nothing other than xdm itself uses this authorization method,
 AFAIK.

 Given this is ugly, and the general approach with other downstream
 projects not to use xdm authorization by default, I figured it was
 simplest to explicitly recommend the configuration override for now.

 Dave

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-amd64/57236 (Gude, 9.8, https://netbsd.org/docs/guide/en/chap-x.html#chap-x-xdm is wrong)
Date: Thu, 2 Mar 2023 10:51:50 -0000 (UTC)

 david@gutteridge.ca ("David H. Gutteridge") writes:

 >From: "David H. Gutteridge" <david@gutteridge.ca>
 >To: matthew green <mrg@eterna.com.au>, gnats-bugs@netbsd.org
 > > so i'm not sure why the xdm-config setting is needed.=C2=A0 or is it
 > > that "XDM-AUTHORIZATION-1" method doesn't work at all, and it
 > > can only be "MIT-MAGIC-COOKIE-1"?=C2=A0 this seems to be the default,

 > So, when the process starts, it loads libxcb, calculates "PID+nonce=3D0+
 > seconds since the epoch" for use by xdm authorization.


 It worked fine when it was invented, nobody would open X sessions on
 multiple threads then.

 The nonce is also just a workaround for not having a truly monotonic
 timestamp. So it could be fixed easily.


Responsible-Changed-From-To: gutteridge->xsrc-manager
Responsible-Changed-By: gutteridge@NetBSD.org
Responsible-Changed-When: Sun, 27 Jul 2025 16:36:50 +0000
Responsible-Changed-Why:
Remaining aspect of this ticket is an xdm bug. (I'm not a proponent of using xdm, so "not me".)

>Unformatted:

Home	PR Database Search