Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!athos.rutgers.edu!mende
From: mende@athos.rutgers.edu (Bob Mende Pie)
Newsgroups: comp.windows.x
Subject: Re: Looking for a program like xtalk...
Message-ID: 
Date: 25 Sep 89 14:54:08 GMT
References: <58273@aerospace.AERO.ORG> <5370@umd5.umd.edu>
Organization: Yows `R' us
Lines: 69

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.

I dont think that a user should ever xtalk someone unless there on an
xdisplay.  Since talk (at least tyhe 4.3bsd version) is usable between
almost any machine, we should use this well known protocal.  Also, this way
you could {talk,xtalk} <-> {talk,xtalk} depending on which users were on x
displays.   One user initiates a (x)talk and that connects to the talk
deamon on the remote machine (no need or what to introduce the concept of
the Xdisplay).   If the user who the talk is going to is on a Xdisplay,
talkd should try to get to the display and get a requestor box.

> Solution: Have the program talk no interaction that requires xhost access.

There are two simple ways to do this.   Since in the protocal I am talking
about talkd will have to be modified, let talkd use the following steps.
1.	find out what display (if any) the user is connected to (not a
	simple problem.)
2.	connect to the talkd on the machine that has that display.   Have
	that talkd (which is on localhost) pop up the requestor box.
3.	The requestor box could be have who the talk is from, where it was
	originally destined and have (accept) (reject) buttons.   If you
	click on accept it will exec (setuid) a XTalk as you.   If you
	reject, it will either go away and let the other person ring on, or
	return "Your Party is not accepting messages" message.

> ... The receiver can allow people to call him by typing a command like
> "xmesg y [-xoptions]" (look familiar?) which will activate a front end
> process that will pop up a ringer window (like xbiff) and set a flag or
> something saying that people can talk to them (much like mesg does).

It is a good idea to have a way to have the equivalant of mesg.  The best
way is to have a XTalk.accept resource.  If it is set to false, then
in.talkd will display the "your party is not accepting messages" string,
othersize pop up the requestor box.   It would be trivial to have xtalk
take a -y -n flag to set this properity.

> My last article posed an answer to xhostless xtalk.
> It probably could be modified to run directly with the talk daemon so that
> one can talk while the other xtalks, but that is really best left to
> the following:
> % xterm -T "XTalk `whoami`" -display  -e talk `whoami` &

This is evil.   I would get very very annoyed if anyone poped up a talk
on my screen without my ok.   A requestor box is a different thing... but
what happens if I dont want to talk to the person doing it.   I will not
run any version like this on any machine I have control of.  The idea of
using xterm as xtalk is what I first thought of.  Of course if you want to
have it have the mesg funcionality, then you will have to have it be a real
program and then exec the xterm (trivial).   

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.   This is the
action that I as a user would expect.   Has anyone at the Xconsortium
thought about how to get the display an arbitray user is on?


					/Bob...
-- 
{...}!rutgers!mende	  mende@aramis.rutgers.edu	   mende@zodiac.bitnet