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