Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.sysv386 Subject: Re: ESIX and MCA Message-ID: Date: 18 Nov 90 14:05:34 GMT References: <5683@crash.cts.com> Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 79 Nntp-Posting-Host: teachk In-reply-to: jca@pnet01.cts.com's message of 17 Nov 90 04:29:28 GMT On 17 Nov 90 04:29:28 GMT, jca@pnet01.cts.com (John C. Archambeau) said: jca> One of the things I have done is rule out getting ESIX for the jca> system that I'm proposing in the next few months. Reason being jca> that security hole that was mentioned awhile back. Since the jca> machine in question will be used as a mailhost and gateway, it jca> would be very foolish to use an OS with even the HINT of a security jca> hole. So right! You remind me of what somebody else says, that the only way to make a computer secure is to place the power switch in the OFF position. But of course you are being intentionally amusing here -- what you write above either demonstrates either a jocular attitude or complete misunderstanding of the problems of mailhost and gateway security, and I cannot believe the latter option. If you were not joking, your statement above would be a classic example of the well known principle that the greatest security hazard is a false sense of security, and the worst possible false sense of security is thinking that security is more of a tools than of a people problem. For example, by way of not mentioning it, you are surely obliquely making fun of SCO Unix, a system whose security system is so complex and obnoxius that most people disable it in haphazard ways by default, possibly leaving themselves less protected than if it were not there to be bypassed! Note that in the hands of a system administrator with a sure grasp of security theory and practice, and a lot of patience and self discipline, as it is obvious you really are, SCO Unix C2 security is a tool that can indeed provide substantial added protection. You are also probably making also fun of all those system administrators that still use sendmail (whether or not the DEBUG option is compiled in by default) instead of smail3, which is far simpler to configure and thus probably more reliable, not to mention that you have sources and can apply corrections instantaneously (the same advantage of course applies to the freely available UCB sendmail, but here you feign ignorance of its availability, and pretend you have to stick with the manufacturer's binary, over which you have no control). jca> Sorry Everex, but if you had a better attitude about fixing things jca> that were broken, then I would reconsider. Now I'm looking at SCO, jca> ISC, Dell, Intel, and UHC. Hahahaha. Even better! You are a good sport. Here you must be making fun at some of these other vendors; probably you are thinking of how much time (months, years!) after patches were posted in this newgroups did any of these release a version of the filesystem that did not have the inode allocation bug. Also, your reference at UHC means that you are pretending to consider SVR4, which is just out, and therefore presumably a poor choice if one wants a stable and well debugged system for reliability and security. I must confess that this way of poking fun at manufacturers and this audience pretending you are naive and do not understand the issues is very amusing. But of course you give away the whole show in the signature: jca> ... | Small memory model only for jca> ... | Unix? Get the (*bleep*) out jca> ... | of here! Here you surpass yourself in subtlety: your irony here is that *all* UNIXes on 386 allow you to run programs _only in the small memory model_ (even if the UNIX kernel actually runs in the large memory model, in a small way :->). Here your sarcasm is based on pretending that you don't know that the small memory model on the 386 has 32 bit offsets and the large one 48 bit pointers, instead of 16 and 32 bits as on the 286! As far as I know only Intel's iRMX allows you to run large memory model (segmented, 48 bit pointers) programs on the 386. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk