Path: utzoo!attcan!lsuc!mnetor!tmsoft!woods
From: woods@tmsoft.uucp (Greg Woods)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit
Message-ID: <1989Apr25.005038.26621@tmsoft.uucp>
Date: 25 Apr 89 00:50:38 GMT
References: <19516@genrad.UUCP> <1319@nusdhub.UUCP> <10075@smoke.BRL.MIL> <881@cetia4.UUCP> <100455@sun.Eng.Sun.COM> <16042@rpp386.Dallas.TX.US>
Reply-To: woods@tmsoft.UUCP (Greg Woods)
Organization: G.A.W. Consulting
Lines: 20

In article <16042@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>In article <100455@sun.Eng.Sun.COM> plocher@sun.COM (John Plocher) writes:
>>In all this talk about ULIMIT don't forget that there is at least one known
>>bug in the AT&T SVr[23] implementation:
>>
>>	% ls -l /etc/passwd
>>	-rw-r--r--  1 root            0 Apr  3 10:44 /etc/passwd
>>	% su
>>	password: xxxxxxx
>
>How'd you do that?  In the absence of a password file entry for root
>will su _really_ let you in?  [ The answer in SVr[12?] is NO ]

Ah, so much for the good old days (BSD4.? on vax) when we used to trick
various daemons into zapping /etc/passwd so that we could login as root.
-- 
						Greg A. Woods.

woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU}
+1-416-443-1734 [h],	+1-416-595-5425 [w]		Toronto, Ontario, Canada