Path: utzoo!attcan!uunet!bloom-beacon!EXPO.LCS.MIT.EDU!keith From: keith@EXPO.LCS.MIT.EDU (Keith Packard) Newsgroups: comp.windows.x Subject: Re: Looking for a program like xtalk... Message-ID: <8909251639.AA00318@xenon.lcs.mit.edu> Date: 25 Sep 89 16:39:53 GMT References:Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 31 In response to Bob Mende Pie >In article <5370@umd5.umd.edu> ziegast@umd5.umd.edu (Eric W. Ziegast) writes: >> One problem with this approach is that the receiver has to have their >> display xhost + to your machine. Due to the fact that X11R3 lacks security >> except for + or - to a machine, I only xhost + to the hosts that I am >> actively using. Having your display xhost + to an X hacker can lead to all >> sorts of nasty things. If some guy out in Alaska (or anywhere) wants to >> xtalk to me, he can't becuase my display won't let him. > The only thing that we dont know how to do is map a tty to a xdisplay. > You could allow for talk user@xdisplay and modify talk and talkd to handle > it, but I think that the fact that a user is on a xdisplay should be > invisible to a user that is somewhere else. Of course, if the user does > not have a display variable set, it should use normal talk. X11R3 provided only host-based access control mechanisms; but X provides support for many access control systems; most of which require private knowledge shared between the display and the accessing program. Such information is not generally availible to a random (even suid-root) program on a random host. A reasonable solution to this is to provide a user-agent which connects to the display and registers the user with a variety of talk daemons. These daemons would then communicate through this user-agent with the user, and communicate with other talk clients using the talkd protocol. The session manager would then start the user-agent and direct it to register with a collection of local machines, to which talk requests might be directed.