Xref: utzoo comp.unix.wizards:25387 alt.security:2430 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!munnari.oz.au!mundamutti.cs.mu.OZ.AU!kre From: kre@cs.mu.oz.au (Robert Elz) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Message-ID: Date: 4 May 91 08:09:40 GMT References: <7299:Apr2510:22:2091@kramden.acf.nyu.edu> <12535@dog.ee.lbl.gov> <15896:Apr2714:35:3991@kramden.acf.nyu.edu> <1991Apr29.041455.2239@athena.mit.edu> Sender: news@cs.mu.oz.au Lines: 49 jik@athena.mit.edu (Jonathan I. Kamens) writes: > Your code may not be available yet, but Project Athena's Zephyr is. Yes, I know about Zephyr, and probably should have mentioned it explicitly - several other people brought it to my attention, for which I thank you all. However, these things aren't quite the same - Zephyr is solving a much bigger problem than most of us need solved, and at least doesn't seem to solve all of the problem that we actually do want to solve, it would seem that the stuff being done here could adequately be turned into Zephyr clients though. Or, perhaps, might be able to be. In particular, we're only interested in interactive messaging (that stuff that currently opens /dev/ttyXX and blats noise onto it). User location, ... are outside our scope, and unnecessary in our environment (its just not that big - furthermore, its not often necessary, you can usually address a user on your local node, he will have arranged for the message to go wherever he wants to reveive messages). But we are very interested in user presentation - the way that the user actually gets to control the way that messages are shown and which particular messages get shown at all (eg: I like a window to appear showing me "biff" (comsat) type output from new messages that arrive, then vanish a couple of minutes later - but I don't want that for "noise" messages I get - where my definition of what is noise changes from minute to minute). That type of control is the heart of the stuff here, and at least from the paper (which I saw in the usenix proceedings originally, and just fetched and read again - using the net is an easier way to find it than hunting through shelves looking for proceedings...) it doesn't appear that this is really what zephyr is doing. Finally - the place I log in (my workstation) is not where I want messages processed, ie: running a "zwgc" process here would be a basic waste of (extremely) scarce workstation resources. Our stuff requires no permanently running processes at all - apart from inetd which is going to be there anyway. Inetd starts a daemon when a message arrives, that daemon becomes me, and does my will to the message. Should someone actually send a message to my workstation (as I said, no user location stuff, people can do that if they desire), that daemon will run for just a short while, redirect the message off to the host where I want to do the processing for it, and tell the sender they sent to the wrong place and are being forwarded. Maybe I should grab zephyr and have a more detailed look at it?? kre