X authentication ????

[Joe Armstrong]

  Thank you very much, I shall try this.

  I'm  really  after  a  "bombproof"  methods that  works  with  badly
configured machines

  /Joe



On Tue, 13 Jan 2004, Shawn Pearce wrote:

> AFAIK, X examines the DISPLAY environment variable, and uses
> that to lookup the cookie.  It seems that the routine is something
> like:
> 
>   1) Try getenv("DISPLAY") in cookies. (Handle "serv:0".)
>   2) Try "localhost:0" + getenv("DISPLAY") in cookies.
>   3) Try gethostname() + getenv("DISPLAY") in cookies.
>   4) Try "localhost:0" in cookies.
>   5) Try gethostname() + ":0" in cookies.
>   6) Maybe try "127.0.0.1:0" in cookies (though this is not normal).
> 
> The DISPLAY environment variable should be set for any X application
> to work properly, and from what I have seen X servers typically set it
> so the above cases would yeild a proper cookie from the .Xauthority
> file.
> 
> Today's shells make it easy enough to change the DISPLAY environment
> variable before running an application, so I don't see any reason why
> this would need to be available as an Erlang command line option.  But
> login systems like gdm, xdm, etc. would set DISPLAY anyway.
> 
> But I think you know all of this already.  :-)
> 
> X also loves to use unix sockets, especially for local connections when
> the administrator or user does not want to expose the X server to
> the network.  In this case, its possible to configure the X server so
> TCP is not available for remote communication, and ex11 won't work.
> Erlang needs gen_unix.  :)
> 
> If unix sockets are being used, the address is "hostname/unix:n" in
> the .Xauthority file, and the local server is very commonly named by
> its actual hostname, and not the string "localhost".
> 
> 
> 
> Joe Armstrong <joe@REDACTED> wrote:
> > 
> > As I understand things authentication works like this.
> > 
> > When you run an X app it reads the (local) .Xauthority file
> > and chooses the cookie of one of the entries in this file to
> > start a session with the server.
> > 
> > This is reasonably secure since a remote program cannot read the (local)
> > Xauthority file. 
> > 
> > To allow remote hosts to run server sessions you can do one of two things:
> > 
> > 	1) do xhosts+ on the servfer machine (dangerous)
> > 	2) get the entry in the server Xauthority file into
> >   the  Xauthority file  on  the  client.  You  do  an "xauth  extract"
> > command on the server to get the cookie - send it to the client and do
> > an "xauth add" command on the client.
> > 
> >   2) Is the preferred method -  1) is unsafe since ANYBODY can connect
> > to your X server and do *anything* (like log all keystrokes)
> > 
> > So how does a local client figure out which Xauthority entry to use?
> > 
> > My code tries the following
> > 
> >    1) try "localhost"
> >    2) if that fails find the local host name
> >       and look that up
> >    3) give up
> > 
> > ie
> > 
> > host2cookie("localhost", Adata) ->
> >     case host2cookie1("localhost", Adata) of
> > 	T = {true, Cookie} ->
> > 	    T;
> > 	false -> 
> > 	    case inet:gethostname() of
> > 		{ok, Host} ->
> > 		    case host2cookie1(Host, Adata) of
> > 			T = {true, Cookie} ->
> > 			    T;
> > 			false ->
> > 			    get_screen_zero(Adata)
> > 		    end;
> > 		_ ->
> > 		    get_screen_zero(Adata) 
> > 	    end
> >     end;
> > 
> > What next do I try 127.0.0.0 then 127.0.0.2 etc .....
> > 
> > Any ideas
> > 
> > /Joe
> > 
> > 
> > 
> > On Mon, 12 Jan 2004, Peter-Henry Mander wrote:
> > 
> > > Hi Joe,
> > > 
> > > In my case with SuSE 8.2 the .Xauthority list simply doesn't contain localhost. There's 127.0.0.2, and the actual hostname too, but not localhost. I'm not sure how or why it's become like this. Using xhost or xauth as a remedy does work.
> > > 
> > > It's no fault of ex11, although the demo does fail silently, there's no supervisor to catch the exit value of sw_driver:wConnect/2.
> > > 
> > > Pete.
> > > 
> > > On Mon, 12 Jan 2004 14:45:19 +0100 (CET)
> > > Joe Armstrong <joe@REDACTED> wrote:
> > > 
> > > > This should not be necessary - I'd really like to know those cases
> > > > where the start procedure fails.
> > > > 
> > > > If authentication fails it is because
> > > > 
> > > >      ex11_lib_driver:get_cookie
> > > > 
> > > > Has not been able to figure out what cookie to use
> > > > 
> > > > If authentication fails then give the commands
> > > > 	
> > > >         > xauth
> > > > 	list
> > > > 
> > > > To see what cookies you have, then stare at the code in  ex11_lib_driver
> > > > and ex11_lib_xauth to figure out what when wrong.
> > > > 
> > > > /Joe
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On Mon, 12 Jan 2004, Peter-Henry Mander wrote:
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > For those who may have difficulties with X11, do the following after make all:
> > > > > 
> > > > > xhost +localhost
> > > > > erl -pa ./lib -pa ./widget.
> > > > > 
> > > > > Pete.
> > > > > 
> > > > > P.s. thanks Joe :-)
> > > > > 
> > > > > 
> > > > > On Mon, 12 Jan 2004 13:39:38 +0100
> > > > > "Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> wrote:
> > > > > 
> > > > > > Excellent!!
> > > > > > 
> > > > > > I've tested it and it works now, even for me :-)
> > > > > > 
> > > > > > I'm glad you managed to implement the "widget = process" in what seems to be a
> > > > > > very nice way. I've been struggling with this issue for long, and couldn't find
> > > > > > enough inspiration and spare time at the same time.
> > > > > > 
> > > > > > best regards,
> > > > > > Vlad
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> 
>