Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NUSVM.BITNET!GBOPOLY1
From: GBOPOLY1@NUSVM.BITNET (fclim)
Newsgroups: comp.sys.apollo
Subject: Re: Processes in GPR_$borrow mode.
Message-ID: <8906150509.AA02550@umix.cc.umich.edu>
Date: 15 Jun 89 05:05:56 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28
X-Unparsable-Date: Thu, 15 Jun 89 13:01:34 SST

>From: conliffe%caen.engin.umich.edu%mailrus.uucp@bbn.com  (Darryl C. Coliffe)
>Organization: U of M Engineering, Ann Arbor, Mich.
>Subject: Re: Processes in GPR_$borrow mode.
>Message-Id: <43d0609a.b11a@falcon.engin.umich.edu>
>References: <8906120536.AA14404@umix.cc.umich.edu>
>
>> However, because root overrides all permission modes, when root issue
>> a write(1) or wall(1), the message will still get thro.
>>
>
>NO NO NO!  Please don't forget that some people DO use borrow mode
>for a reason, and undesired information appearing at unexpected times o
>a workstation screen can ruin work, too!

Yes I agree; breaking in GPR_$borrow mode violates the very idea of
Dennis Cottel's gone program which locks the node using GPR_$borrow mode.

*However*, please note that I have qualified myself by saying that I need to
know
how a superuser like root or user.sys_admin may break into the borrow mode.
Not every Tom, Dick and Harry should be able to do that.  And a supervisor
only do it if there's an urgent message need to send via send_alarm.

fclim          --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.