Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: ps and wall; How do they work?
Message-ID: <13859@smoke.BRL.MIL>
Date: 14 Sep 90 19:52:15 GMT
References: <13850@smoke.BRL.MIL> <27XgP3w163w@mudos.ann-arbor.mi.us>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 41

In article <27XgP3w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>> Any version of "wall" that writes on terminals that have had "mesg n"
>> executed on them is BROKEN.  You can fix that by removing /bin/wall.
>I disagree.  When you're shutting the system down, it's definitely a
>good idea to let the other people on it know at least a few minutes in
>advance about the shutdown.  If they have write perms turned off and
>/bin/wall won't tell them about it, how do you notify them?

You're making the standard mistake that causes many applications to be
less useful than they ought to be -- you're assuming a specific usage
model rather than allowing for the unlimited flexibility that UNIX caters
to.  Specifically, you assume that there is a person looking at data that
is sent to every tty special device.  In many environments, that is far
from correct.  For example, in mine there are printers attached to some
ttys, with generic output blocked deliberately to prevent messing up what
they are in the process of printing, and other ttys are being used for
binary communication between cooperating processes (one on the host and
one in the terminal).  Generic write access is turned off on such ttys
for a REASON, and it is utterly inappropriate for some unrelated
application to presume that it knows best and override the write block.

If a tty being used in accordance with your model has write access denied
deliberately by the person using the terminal, that is because that person
has decided, for whatever reason, that he does not want to receive output
from foreign sources for the interim.  Who are you to ignore his wishes?
Maybe it is important for him to hear about impending system shutdown, etc.
or maybe it isn't -- however, he has assumed the responsibility for not
receiving "wall" messages and it is not proper for "wall" to second-guess
his intentions.

>But just like with write(1), the superuser should be able to send messages
>even to users who have done a "mesg n".

I also disagree with the assumption that it is proper to log in as root
merely in order to exploit UNIX's intentional access permissions loophole.
But in any case, neither "write" nor "wall" should communicate with
"terminals" that have deliberately had external access denied for them.

What is really needed is proper session and terminal management, but
lacking those we should at least honor deliberate user decisions.