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.