mailer-daemon%cernvax.cern.ch@pucc.princeton.edu (12/18/90)
Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN@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 Tue, 11 Dec 1990 V11#058
Today's Topics:
Re: Jargon file v2.1.5 28 NOV 1990 -- part 1 of 6
Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
Re: recently created newsgroups
Re: non-superuser chown(2)s considered harmful
Re: Serial I/O
captoinfo(1M) and infocmp(1M) sources wanted. I have ftp.
Process history under C-shell and Bourne shell
flaky DEUNA board on VAX 11/750
Re: Problems with the crontab
Re: gets() during signal
The performance implications of the ISa bus
Re: Ok... can we switch it back now?
IO buses, memory waste
Re: How do you find the symbolic links to files.
Unix files should have both real and effective ids for files too
Re: Now that resolver is used, mail ignores 'mailhost' in /etc/hosts
Re: Preventing date rollback
Include a postscript source file into Troff
-----------------------------------------------------------------
From: Jan Mattson <janm@puckstang>
Subject: Re: Jargon file v2.1.5 28 NOV 1990 -- part 1 of 6
Date: 10 Dec 90 11:22:32 GMT
Sender: news@kuling.uucp
Organisation: CS Dept, Uppsala University, Sweden
To: unix-wizards@sem.brl.mil
In <207@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes:
>Thus spake eric@snark.thyrsus.com (Eric S. Raymond):
>> BUG [from telephone terminology, ``bugs in a telephone cable'', blamed
>> for noisy lines] n. An unwanted and unintended property of a
>> program, esp. one which causes it to malfunction. See FEATURE.
>I have heard this attributed to Rear Admiral (retd) Grace Hopper, who
>had a malfunctioning program. The cause was traced to a fried moth in
>the back of the computer.
The use of the word "bug" to describe "unwanted and unintended" behavior
is much older than computers. Edison used it, and perhaps it's even older
than that.
--
Jan Mattsson
Computer Science student, Uppsala University, Sweden
Email: D88.Jan-Mattsson@carmen.docs.uu.se or janm@zorn.csd.uu.se
-----------------------------
From: "Darragh J. Delany" <darragh@maths.tcd.ie>
Subject: Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
Date: 10 Dec 90 17:35:46 GMT
To: unix-wizards@sem.brl.mil
In article <PCG.90Dec5162259@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo
Grandi) writes:
}On 30 Nov 90 17:25:12 GMT, smith@sctc.com (Rick Smith) said:
}smith> A Unix hacker can't sneer at Multics. It's like sneering at your
}smith> grandad. Sure he's a doddering wreck, but he created some pretty
}smith> fine stuff that we can still be proud of. You, for example.
}If only! A very good argument can be made that Multics is a descendant
}of Unix! You can consider Multics the grandchild of Unix.
If I remember rightly the very name Unix was a pun on Multics
which was the epitomy of what an efficient operating system
should not have been.
Darragh.
-----------------------------
From: "Laird J. Heal" <laird@chinet.chi.il.us>
Subject: Re: recently created newsgroups
Date: 10 Dec 90 12:55:58 GMT
To: unix-wizards@sem.brl.mil
In article <Dec.3.01.34.46.1990.22951@turbo.bio.net> lear@turbo.bio.net (Eliot)
writes:
>
>The following newsgroups were created based on the guidelines in the
>last two weeks:
>
> Dec 3 soc.culture.lebanon
> Dec 3 rec.arts.fine
> Dec 3 comp.sys.acorn
> Nov 25 comp.sys.novell
> Nov 25 comp.research.japan
> Nov 25 sci.engr.chem
> Nov 25 rec.games.pinball
> Nov 25 rec.audio.car
I have been sending the mass acknowledgement and results to
news.announce.newgroups, as the guidelines suggest. However, they have not
been posted, while I never had any problems before and they have not beenmailer-daemon%cernvax.cern.ch@pucc.princeton.edu (12/18/90)
Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN@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@ncsuvm.ncsu.edu
Subject: keyboard control
Date: 11 Dec 90 19:17:08 GMT
To: unix-wizards@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@phys.physics.ucf.edu. Thank
-----------------------------
From: FDHEIENO@ucf1vm.cc.ucf.edu
Subject: video ram
Date: 11 Dec 90 19:25:41 GMT
To: unix-wizards@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@phys.physics.ucf.edu. Thanks for the help!
-----------------------------
From: FDHEIENO@ucf1vm.cc.ucf.edu
Subject: xenix tracks
Date: 11 Dec 90 19:32:08 GMT
To: unix-wizards@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@phys.physics.ucf.edu. Thanks for the
help!`
-----------------------------
From: John F Haugh II <jfh@rpp386.cactus.org>
Subject: Re: Complex security mechanism is unsecure
Date: 12 Dec 90 13:46:05 GMT
To: unix-wizards@sem.brl.mil
In article <6874@titcce.cc.titech.ac.jp>, mohta@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