Bug#75344: startx can fail to regenerate X auth cookie

[Vincent Zweije <zweije@xs4all.nl>]

On Mon, Oct 23, 2000 at 08:44:37AM -0500, Branden Robinson wrote:

||  The reason I wrote that part of startx the way I did was due to the
||  following scenario:
||
||  1) user has a display manager managing :0
||  2) user logs in on :0, creating XDM-AUTHORIZATION-1 cookie for :0
||  3) user switches to a VC
||  4) user absent-mindedly runs startx without arguments
||  5) startx creates MIT-MAGIC-COOKIE-1 cookie for :0
||  6) X server bombs out, finding :0 already active
||  7) startx removes all cookies for :0
||  8) user goes back to xdm-managed :0 session
||  9) user can't start any new X clients, since all :0 cookies are gone
||
||  Fortunately startx is not setuid root (and doesn't need to be) or any user
||  could do steps 3-7 and it would be a denial-of-service attack.
||
||  Even so, the situation described above is a bit confusing, and definitely
||  not desirable.  Do you have a suggestion that will accomplish what we both
||  want?

Have startx check if the X server is already there, and if so, abort
before generating a cookie.  Just a tiny program that tries to connect
to /tmp/.X11-unix/XD.

Another solution is for xinit to include this check, and have xinit
itself generate the necessary authorization record instead of leaving
that to the startx script.

Alternatively, the new cookie could be generated into a separate temporary
file (not .Xauthority) and copied into .Xauthority as the first thing
the session script does.

So, lots of ideas.  I think I prefer the latter as a quick fix, or the
xinit way as a more structural one.

Ciao.                                                        Vincent.