"bad ulimit" on all non-root "at" & "batch" jobs under 386/ix

[James Van Artsdalen]

In <1990Jan30.142000.5253 at virtech.uucp>, cpcahil at virtech.UUCP (Conor P. Cahill) wrote:

> ulimit and quotas are two different things!

Yes, quota works and ulimit does not.  If it actually merely caught
programs using lots of disk space, fine.  That is not actually what it
does.

> ulimits (and BSD resource limits) are there to catch a run-away program
> from eating up too much space.  

What ulimit actually does it prevent writing beyond a certain file
offset in any regular file.  There is not an absolute relationship
between the file offset and the amount of data written.

My original example still holds: a user posting a news article causes
inews to fail writing the history file.  Perfectly legimate, perfectly
ordinary.  Why should a ulimit-type system consider inews, writing
probably less than 200 bytes to history, to be run-away?

| ulimit is basically an example of what was wrong with AT&T unix (as
| opposed to BSD) for a long time: no one at AT&T cared if the product
| was usable/competitive or not.  Someone had a file fill a filesystem

> If you want to bash at&t without thinking about what you are saying, go
> ahead.  However you might want to know that BSD does provide the same
> functionality as ulimit so they must have thought it was usefull.

I not only thought about it, I suffered with the problem and went and
read the source.  I do confess that I didn't read the BSD source to
see if they handled the resource limit stuff right.  I also haven't
checked to see if that resource limit is enabled by default (you can
bet it won't be 1meg).

If the AT&T programmer had thought correctly, they would have realized
that the correct thing to do would be to (1) count blocks actually
allocated so that a program would really be allowed to write it's full
ulimit.  It's clear that the file offset model doesn't really address
the problem: it's a cheap way out.  (2) the ulimit should be reset to
some system default on exec(2) to an suid program.  #2 raises issues
about what ought to happen with sgid programs, but it's clearly
solvable.
-- 
James R. Van Artsdalen          james at bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789