Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!decuac!cvl!umd5!zben From: zben@umd5.UUCP Newsgroups: comp.sys.mac Subject: Re: UW talk problem Message-ID: <1529@umd5.umd.edu> Date: Mon, 13-Apr-87 13:22:02 EST Article-I.D.: umd5.1529 Posted: Mon Apr 13 13:22:02 1987 Date-Received: Wed, 15-Apr-87 00:49:50 EST References: <213@phoenix.PRINCETON.EDU> Reply-To: zben@umd5.umd.edu (Ben Cranston) Organization: University of Maryland, College Park Lines: 45 Summary: Problem analysis 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"