Xref: utzoo news.software.b:6547 comp.unix.admin:758 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!decwrl!mcnc!wolves!ggw From: ggw%wolves@cs.duke.edu (Gregory G. Woodbury) Newsgroups: news.software.b,comp.unix.admin Subject: Re: (C News) (u)limit filesize and inews Message-ID: <1991Jan6.041145.22955@wolves.uucp> Date: 6 Jan 91 04:11:45 GMT References: <27839439.1746@ics.uci.edu> <1991Jan3.214226.9184@zoo.toronto.edu> Followup-To: comp.unix.admin Organization: Wolves Den UNIX Lines: 54 X-Checksum-Snefru: 69b90d5c 9a244fcd ce7501bd 2bade78a In article <1991Jan3.214226.9184@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <27839439.1746@ics.uci.edu> nagel@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@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ]