Undeliverable mail to VMS host

[mailer-daemon%cernvax.cern.ch at pucc.princeton.edu]

Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
 not be delivered.
The error message was:

Deferred: %MAIL-E-OPENOUT, error openning as output

This message is equivalent to the DECnet-VAX error message:

 -SYSTEM-F-EXDISKQUOTA, disk quota exceeded

The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.


====== The start of Your original message ======

UNIX-WIZARDS Digest          Thu, 13 Dec 1990              V11#060

Today's Topics:
                            keyboard control
                               video ram
                              xenix tracks
               Re: Complex security mechanism is unsecure
             Re: non-superuser chown(2)s considered harmful
                           Password and gecos
                                  test
                           PROCESS MIGRATION
            Re: How to get past end of cpio archive on tape
             Re: non-superuser chown(2)s considered harmful
Re: Complex security mechanism is unsecure (was Re: non-superuser chown(2)s
 considered harmful)
                             Re: Serial I/O
                      SLIP for a 3B2 running 3.2.2
                       PROCESS MIGRATION IN UNIX
            Re: How do you find the symbolic links to files.
             Re: non-superuser chown(2)s considered harmful
            Re: How do you find the symbolic links to files.
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
                          What do I do wrong?
                               Unix Feuds
                        Re: What do I do wrong?
            Re: How do you find the symbolic links to files.
            Re: The performance implications of the ISA bus
             Re: non-superuser chown(2)s considered harmful
               Re: Complex security mechanism is unsecure

-----------------------------------------------------------------

From: FDHEIENO%ucf1vm.cc.ucf.edu at ncsuvm.ncsu.edu
Subject: keyboard control
Date: 11 Dec 90 19:17:08 GMT
To:       unix-wizards at sem.brl.mil

In DOS, it's easy to detect whether a user has pressed ALT+F1, SHIFT+F1,
CTRL+F1, etc.  In Xenix, how do you detected whether a user has pressed
ALT + a, or ALT + F1, or any keystroke combination that involves the ALT key?
Please email responses to dfw at phys.physics.ucf.edu.  Thank

-----------------------------

From: FDHEIENO at ucf1vm.cc.ucf.edu
Subject: video ram
Date: 11 Dec 90 19:25:41 GMT
To:       unix-wizards at sem.brl.mil

In DOS, video ram can be accessed by B000 (mono) or B800 (color) to perform
fast screen refresh.  How can this be done in Xenix?  If not possible (or
horribly complicated), what's the next best method?  Please email responses to
dfw at phys.physics.ucf.edu.  Thanks for the help!

-----------------------------

From: FDHEIENO at ucf1vm.cc.ucf.edu
Subject: xenix tracks
Date: 11 Dec 90 19:32:08 GMT
To:       unix-wizards at sem.brl.mil

Is there a way to read the contents of a given track and put the data into
a file for inspection?  I`m thinking of cases where a track may go bad, and
the data needs to be recovered before marking the track bad with 'badtrk' in
Xenix.  Please email responses to dfw at phys.physics.ucf.edu.  Thanks for the
help!`

-----------------------------

From: John F Haugh II <jfh at rpp386.cactus.org>
Subject: Re: Complex security mechanism is unsecure
Date: 12 Dec 90 13:46:05 GMT
To:       unix-wizards at sem.brl.mil

In article <6874 at titcce.cc.titech.ac.jp>, mohta at necom830.cc.titech.ac.jp
 (Masataka Ohta) writes:
> In the latter case, you must be careful that no unauthorized person can
> have uucp nor root priviledge. If you have an executable owned by uucp
> in root's command serach path (like /usr/bin/tip), those who have uucp
> priviledge can easily set a trojan horse trap.

sure, and any program owned by "bin" which is in root's command search
path is also likely to be a trojan horse.  most of the programs in /bin
have that property.  this is why "bin" shouldn't have a password unless
you are willing to have the owners of "bin"'s password become "root"
someday.  and the same applies, of course, to "uucp" and "sys" and so on.

> >Unfortunately, if you have an application that
> >wants to change the ownership to the user, such as cu, you must now
> >make cu set-UID to "root".
>
> But it is more secure.

not true - read on.

> So, don't make the security mechanism complex. The simpler, the more secure.

this part is true - the number of things which you must protect against
with "root" being the effective user ID is far greater than the number
of failure modes with a program set-UID to "uucp".  "uucp" has no