pswisnov@phoenix.UUCP (04/12/87)
For people using uw and who are having problems using talk and write, try rlogin'ing onto your machine again in another window: you should be able to use talk and write from that one.
zben@umd5.UUCP (04/13/87)
In article <213@phoenix.PRINCETON.EDU> pswisnov@phoenix.UUCP (Peter S. Wisnovsky) writes: > For people using uw and who are having problems using talk and write, > try rlogin'ing onto your machine again in another window: you should > be able to use talk and write from that one. This problem appears to be due to security considerations and varies on a machine to machine basis. For example, on this system I can use write but not talk, since write appears to be virgin but talk has some security code added in. It appears to be due to the UW server's inability to write the "utmp" file with a "login" record for the new ptty associated with each new window. There are a few lines of code in the server which are commented out. If you can persuade your local gurus to make the UW server setuid-root you can turn these lines of code on, and it *looks* like the utmp write will be correctly done. I say "looks" because I haven't been able to persuade the gurus of this machine to do so... Here's the code from lines 96 thru 108 of module uw_main.c: /* * If we can open the "/etc/utmp" for write, do so. * Immediately afterwards, we lose any magic powers that * might have allowed us to do this. */ #ifdef UTMP fd = open("/etc/utmp", O_WRONLY); (void)setgid(getgid()); (void)setuid(getuid()); if (fd >= 0) fdmap[fd].f_type = FDT_OTHER; utmp_init(fd); #endif Also, fair warning, I once tried to rlogin to the same machine as uw was running on, but to a different user, and the thing went into a loop opening and closeing windows and the machine eventually had to be rebooted. Needless to say I haven't done much more experimentation, so I can't say if this is specific to any local code at UMD5. But, be warned... -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
schwartz@swatsun.UUCP (04/14/87)
In article <213@phoenix.PRINCETON.EDU>, pswisnov@phoenix.PRINCETON.EDU (Peter S. Wisnovsky) writes: > For people using uw and who are having problems using talk and write, > try rlogin'ing onto your machine again in another window: you should > be able to use talk and write from that one. This certainly ought to work, but there might be a simpler solution. On Sun workstations, /etc/utmp is world writable, and so UW can properly install each window. But for this to work properly, you have to make sure that all the pseudo-ttys are listed in /etc/ttys. In Sun3.2 this is the case, but it was not the case in Sun3.0. -- Scott Schwartz @ Swarthmore College Computer Science Program UUCP: ...{{seismo,ihnp4}!bpa, cbmvax!vu-vlsi, sun!liberty}!swatsun!schwartz AT&T: (215)-328-8610 /* lab phone */
jdb@mordor.s1.gov (John Bruner) (04/14/87)
The code in the UW server which is compiled if UTMP is defined does write entries into "/etc/utmp". On some machines the utmp file is world-writeable (e.g. on Suns, so that "suntools" can write it); on others UW must be setuid or setgid in order to write it. The code in the server handles windows created from the Mac (with the "New" command in the "Window" menu) and windows created via "uwtool". "uwterm" does its own pseudo-terminal management and does not write into the utmp file. (I didn't have time to implement and test that before the last distribution.) A general word of advice: you should be very cautious about installing setuid/setgid programs. I advise you to look at any such program (certainly including the UW server) very carefully so that you understand the implications of installing it setuid or setgid. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.s1.gov (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb