Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!rutgers!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.i386
Subject: Re: Unix for a 386.
Message-ID: <1989Aug26.171834.8492@ddsw1.MCS.COM>
Date: 26 Aug 89 17:18:34 GMT
References: <1989Aug16.020438.5662@esegue.uucp> <7186@megatest.UUCP> <1792@crdgw1.crd.ge.com> <509@loft386.UUCP> <1989Aug24.210014.1854@eci386.uucp> <123668@sun.Eng.Sun.COM>
Reply-To: karl@ddsw1.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 28
Summary: Microport's "security" was real easy to bypass

In article <123668@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes:
>>I would
>>guess that the crippling is in getty, or login because I understand you
>
>Microport's setup involved getty and kernel internals - if you replaced
>getty with your own version then the system would fail to boot and print a "L"
>on the screen.  The intent was to have a user call in and "give himself in" - 

Only if he wasn't literate with the Unix system.

It turned out that even for unlimited licenses you still had to keep the real
getty on the console, or the system would barf.

However, the remainder of the lines could be spawned off something else,
eg: /etc/autobaud.

We discovered this the hard way on our _unlimited_ kernel when the system
wouldn't come back up after installing our replacement getty.

I wasn't pleased, but the fix was very, very simple :-)  While I never
checked it, I suspect that our methodology probably would have worked to 
bypass the "user limit" as well.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"