Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!ut-ngp!melpad!bigtex!james From: james@bigtex.uucp (James Van Artsdalen) Newsgroups: comp.unix.questions Subject: Re: ulimit considered braindamaged ? Message-ID: <211@bigtex.uucp> Date: Mon, 5-Jan-87 11:30:32 EST Article-I.D.: bigtex.211 Posted: Mon Jan 5 11:30:32 1987 Date-Received: Mon, 5-Jan-87 23:12:28 EST References: <790@maynard.BSW.COM> <196@devon.UUCP> Sender: news@bigtex.uucp Reply-To: james@bigtex.UUCP (James Van Artsdalen) Organization: F.B.N. Software, Austin TX Lines: 19 Keywords: ulimit SysV irksome IN article <196@devon.UUCP>, paul@devon.UUCP (Paul Sutcliffe Jr.) wrote: > The problem here is that ulimit is a builtin to the Bourne shell (the > csh does not know about ulimit, but does honor the default). csh does not exactly have a choice in whether or not to obey the ulimit. And I don't see what the built-in command ulimit has to do with the problem. > It's also interesting to note that _any_ process running as set[e]uid > root does not adhere to the ulimit value (e.g. can write to any size > file). It is indeed interesting, as root *does* adhere to the ulimit in System V (unless vendors outside AT&T have changed the code from S5r2.0.4). Set "ulimit 50" from root and try to "cat big_file >/tmp/q" and cat will return an error. cpio also catches the error (I have run into this more than once working with very large backup files). It makes no difference whether or not uid == euid. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Voice: (512)-323-2675 Modem: (512)-323-2773 5300B McCandless, Austin TX 78756