foonberg@groucho.Aero.Org (Alan Foonberg) (09/22/89)
...except that one party does not have to be running X Windows. That is, the non-X user runs an X application on the display of the X user. It would be similar to xtalk, except that the non-X user would see a display on his terminal similar to the usualy talk program. I imagine this could be hacked up pretty quickly. If anybody has done so, is planning on doing so, or knows where such a program exists. could he let me know? Thanks, Alan Foonberg foonberg@aerospace.aero.org
mende@athos.rutgers.edu (Bob Mende Pie) (09/23/89)
In article <58273@aerospace.AERO.ORG> foonberg@groucho.Aero.Org (Alan Foonberg) writes: > ...except that one party does not have to be running X Windows. > That is, the non-X user runs an X application on the display of > the X user. It would be similar to xtalk, except that the > non-X user would see a display on his terminal similar to the > usualy talk program. > > I imagine this could be hacked up pretty quickly. If anybody > has done so, is planning on doing so, or knows where such a > program exists. could he let me know? I looked into doing this a good bit ... when you look at the whole problem, you will se that there is more problem then you would expect. Lets base the program on the standard bsd talk protocal. If you are on your xdisplay, you type xtalk user@host, a window pops up and iniatiates a talk with some other user. I did this part in a one line shellscript using xterm and a class name. Now ... say that the person that you talked is also using a xdisplay. You talked user@heckle since that is where he is logged in. But little to your knowledge, his heckle window is closed, and has been for hours. A normal talk message might go unnoticed. To complicate things, his xdisplay is jeckle. Thus talkd on heckle has to find out where user's display is, open either a talk on this display, or open a requestor box on his display. The requestor box is also simple, the hard part is finding out where his display is. Where do you get jeckle:0.0 from. The three possibilities are a) from some magic file (this is loosing for all the obvious reasons) b) from the users enviorment. Of course this means that talkd has to check to see if your logged in and then prowl through your enviorment, and hope you have a display enviorment variable set. c) get it from some other mechanism that does not yet exist. While c is the best choice, b is the most likely implementation. Tbere should be some way to identify where your xdisplay is located. If people want system services to interact with X, this will have to be standardized. /Bob... -- {...}!rutgers!mende mende@aramis.rutgers.edu mende@zodiac.bitnet
ziegast@umd5.umd.edu (Eric W. Ziegast) (09/25/89)
In article <Sep.23.03.28.29.1989.15161@athos.rutgers.edu>, mende@athos.rutgers.edu (Bob Mende Pie) writes: > Now ... say that the person that you talked is also using a xdisplay. >You talked user@heckle since that is where he is logged in. But little to >your knowledge, his heckle window is closed, and has been for hours. A >normal talk message might go unnoticed. To complicate things, his xdisplay >is jeckle. Thus talkd on heckle has to find out where user's display is, >open either a talk on this display, or open a requestor box on his display. > The requestor box is also simple, the hard part is finding out where his >display is. Where do you get jeckle:0.0 from. The three possibilities are >a) from some magic file (this is loosing for all the obvious reasons) b) >from the users enviorment. Of course this means that talkd has to check to >see if your logged in and then prowl through your enviorment, and hope you >have a display enviorment variable set. c) get it from some other >mechanism that does not yet exist. While c is the best choice, b is the >most likely implementation. > Tbere should be some way to identify where your xdisplay is located. >If people want system services to interact with X, this will have to be >standardized. 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. Solution: Have the program talk no interaction that requires xhost access. One way thought up around here was to create a daemon on the machine that handles all xtalk requests just like talkd does for talk. 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). Now to call that receiver, all someone has to do is "xtalk receiver@receiver-host". (Note the absense of :0.0) The xtalk pro- gram will send a message to receiver-host's xtalk daemon and let the daemon send a signal to the ringer on receiver's display to make in "ring". At that point, the user can through a response like "xtalk -answer" send a signal back to the caller to have the connection made (At this point win- dows on each one's display controlled by each one's host pop up to talk with.) To make a long story short, recreate the talk program and daemon with each machine having a front-end program to control the display. I have many ideas but not the knowlege to implement them. (So don't ask me for source code. :-) I know enough X to know what you can do and what you can't do, but not enough to program. (Sort of like knowing everything you can make twm do without ever touching or looking at the source code.) If anyone wants to take a shot at this, feel free. I release all copyrights to this idea. Eric W. Ziegast Disclaimers: "uucp!haven!umd5!ziegast".UUCP Any opinions expressed are my own and ziegast@umd5.umd.edu (InterNet) not of any company or institution. ziegast@umdc.BITNET (Bitnet) All opinions are sold "as is." Eric@(301)985-0724 (PhoneNet) No refunds or exchanges accepted.
ziegast@umd5.umd.edu (Eric W. Ziegast) (09/25/89)
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 <disp_name> -e talk `whoami` & Message from Talk_Daemon@umd5.umd.edu at 22:30 ... talk: connection requested by ziegast@umd5.umd.edu. talk: respond with: talk ziegast@umd5.umd.edu % talk `whoami` What this does is does is pop up an xterm on the remote user's display <disp_name> that will execute a talk to yourself. So in that window that other person will be talking to you through your own talk. An added -geom option won't grab their mouse. Exiting talk will also exit xterm and therefore get rid of the window. I have done this many times to talk to people on Sun's who have a snoddy, stuck up talk daemon that says [Looking for invitation on caller's machine] and hangs forever (i.e. "Don't call us, we'll call you"). Just popping it on their display avoids connection protocol. Of course xhost + to your machine is a prerequisite. Eric Z
J.Crowcroft@ucl-cs.UUCP (09/25/89)
From: Jon Crowcroft <J.Crowcroft@uk.ac.ucl.cs> >I have many ideas but not the knowlege to implement them. (So don't ask me >for source code. :-) I know enough X to know what you can do and what you >can't do, but not enough to program. (Sort of like knowing everything you >can make twm do wit >hout ever touching or looking at the source code.) >If anyone wants to take a shot at this, feel free. I release all copyrights >to this idea. Eric, i posted a simple n way x talk - ish type proggy to comp.sources.x a while back - it wasnt bug free, and i have only had a few (but useful) comments back on it - it used rusers (sun rpc) to locate users, so you didnt need to know where the users were logged in (i didnt hack it to find which display they were on, or whether it ran X at all...) coz the top level popped up, you got a notification that someone was trying to chat, and you could add and delete members of the thingy while running...i can describe more if you like - some people here actually use it!! jon (p.s. i think its a discovery, not an invention, so not copywritable...)
mende@athos.rutgers.edu (Bob Mende Pie) (09/25/89)
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 <disp_name> -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
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/25/89)
> Has anyone at the Xconsortium > thought about how to get the display an arbitray user is on? not a lot, but Project Athena has. See DellaFera, et. al, 'The Zephyr Notification Service', USENIX Conference Proceedings, Winter 1988, pp. 213. The basic approach is to declare Yet Another Network Service which is a database mapping (among other things) usernames to displays.
keith@EXPO.LCS.MIT.EDU (Keith Packard) (09/25/89)
In response to Bob Mende Pie <aramis.rutgers.edu!athos.rutgers.edu!mende@rutgers.edu> >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.