Path: utzoo!utgpu!watserv1!watmath!att!rutgers!apple!agate!ucbvax!unisoft!greywolf From: greywolf@unisoft.UUCP (The Grey Wolf) Newsgroups: comp.unix.internals Subject: Re: Trojan Horses Message-ID: <3173@unisoft.UUCP> Date: 17 Oct 90 22:12:34 GMT References: <1990Oct7.155203.13283@hq.demos.su> <18578@rpp386.cactus.org> Reply-To: greywolf@unisoft.UUCP (The Grey Wolf) Organization: Foo Bar and Grill Lines: 33 In article <18578@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: # In article <1990Oct7.155203.13283@hq.demos.su> avg@hq.demos.su (Vadim G. Antonov) writes: # # > 2) All processes, associated with a TTY should be killed # > (as SIGHUP does) andprotected processes should be # > RE-ASSOCIATED with an unique TTY-id (which actually # > does not exist). # # Killed is a tad strong. The only real requirement is that unauthorized # access to the device be revoked. You can do this simply by marking a # file table entry which references the device as "stale" and returning # an error on any attempt (other than close, I suppose ...) to use that # descriptor. I believe this is what the vhangup() call does. Or used to. I don't know what has taken its place, but I have heard rumours of the demise of this call... # John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh # Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org # "SCCS, the source motel! Programs check in and never check out!" # -- Ken Thompson I wonder, incidentally, why does close() return something? Is it just that it's a system call? What checks for close()'s return value? I could see it being used for security checks and such, I suppose (verifying that "fd %d had to be closed -- CHECK THIS"). -- "This is *not* going to work!" "Well, why didn't you say so before?" "I *did* say so before!" ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf