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.
