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