(C News) (u)limit filesize and inews

Gregory G. Woodbury ggw%wolves at cs.duke.edu
Sun Jan 6 15:11:45 AEST 1991


In article <1991Jan3.214226.9184 at zoo.toronto.edu> 
henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <27839439.1746 at ics.uci.edu> nagel at ics.uci.edu (Mark Nagel) writes:
	[situation where updating history file or something hits the
filesize resource limit (ulimit) and inews fails.]

>>...Given that this guess is correct, should relaynews ensure
>>that it's resource limitations are appropriate...
>
>This would be a good idea, were it possible.  The problem is that such
>limitations are extremely unportable and code that manipulates them is
>even more so.  In addition, often you need superuser privileges to
>raise or remove a limit.
>
>I'm not sure what the solution to this is, but contorting *every* program
>a user might invoke that might have to modify a big database is not it.
>Especially when such programs may be shell files that have considerable
>trouble coping with such stupid impositions.  It would make a whole lot
>more sense if the kernel disabled such limits for setuid programs.  The
>list of things that setuid programs have to worry about is already
>excessively long; we don't need gratuitous additions to it courtesy of
>stupid implementors.
>
>(If you think news history is a bad case, consider the result of hitting
>such a limit while updating /etc/passwd and friends.)

	Actually.... I had a system that did hit ulimit troubles while
updating /etc/passwd!  One SVr3.0 system had a small ulimit (10K) due
to some administrative argument (one boss said limit file sizes, another
said thats stupid, the 1st one won for 5 days - until this and other
things happened.)  It just happened that the passwd file was just over
the size limit (by about 512 bytes) and all sorts of hell broke loose.

	Users passwords were expiring and noone could change their
passwords (cause the rewrite of /etc/passwd would hit ulimit and
fail-safe back to the original file); but they couldn't log in cause
their passwords had to be changed; but they could not change the
passwords..........

	Even in the face of a "fail-safe" (keep the old version if you
can't write the new version) the system became useless.  (Just think if
the root had had password aging and its password expired in that time
frame! - can you say SOL?  I knew you could!)  Never heard a response to
this one!  I haven't had the guts to see what would happen if
/etc/shadow hits ulimit for a passwd change.

			Just another anecdote for the grist mill.

			Greg
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...mcnc!wolves!ggw           [use the maps!]
Domain: ggw at cds.duke.edu     ggw%wolves at mcnc.mcnc.org
[The line eater is a boojum snark! ]           <standard disclaimers apply>



More information about the Comp.unix.admin mailing list