Les Mikesell wrote:
Just read your comments below, Les. The list deserves a response but it will have to wait. Your views don't deserve any of my early a.m. time.
On Sat, 2005-03-19 at 21:29, David Curry wrote:
No, the assumption is that the person installing the OS, expert orYour interpretation would be much better supported if there was some documentation available to that "person installing the OS" which informed them of the default installation settings and advisability of resetting for specific installation characteristics.
not, knows more about it's capabilities than the person who
built the distribution that will run on anything from a P100
or less to a multi-cpu, multi-Ghz box.
I simply can't believe that anyone who is obviously on the internet and capable of joining a mailing list can possibly think there is any lack of documentation available. It is true that a free product generally does not come with a marketing force that will take you to lunch or golf and hold your hand while you learn about the product, but the ulimit concept has been documented for anyone who cares to read about it long before Linux was even around (remember how Linux is a free implementation of the unix API...).
This argument overlooks the specifc kind of concern that prompted the thread originating author to pose his question. Namely, vulnerability of the system to fork bombing if it is hacked.
Well, OK - don't get hacked. A fork bomb is one of the least destructive things a hacker could do once in. Keep your system updated and you are unlikely to have a vulnerability exploited. Keep your password to yourself, don't write it down, and don't use it over public unencrypted connections.
See my responses to your two preceeding assertions.You are the one making the wrong assumption if you think the OS distributors know more about how *your* PC's resources should be used or how much you trust the other users on your machine.
I saw them, but they do nothing to address the point that no one else can understand your situation to pick appropriate limits.
Second guessing an ops "decision to start an inefficiently large number of processes" would be to predetermine limits below capacity and not provide a means of changing them. Setting installation default at a level large enough to handle installation while providing both advice of those default settings and a means of changing them to suit the user would be prudent as well as rational. It would be better practice Red Hat/Fedora than has been followed in the past.
That would be like buying a car that would not go above 5 mph until you prove your proficiency under the hood to remove the limit. While it might be a good practice for some definition of the term, it isn't what anyone would expect.
Is it a fact that 'fork bombs' require "login/password access ... to set them off." We recently read here on fedora-list about a system that had been taken over and was being used without authorization as a mail server. A script of unknown original found in the /tmp directory set up the service.
Breakins are equivalent to gaining a login/password. Finding out about it through a system crash or slowdown is probably better than letting an outsider continue to use your system resources and likely intercept logins and passwords you are using in your outbound connections to other sites. In other words, the fork bomb potential is the least of your problems after a breakin.
Controling system access is the objective. But, doesn't it make sense to maintain multi-layered defenses so if the outer perimeter is breached more hurdles exist to thwart stealth attackers?
It doesn't make sense to impose limits on the legitimate user(s) of the system by default. Did you pay for those hardware resources just to be prevented from using them to their limits?
And, to limit the chances of anyone else breaching my system's security
and damaging my system, I have now established new, lower resource
allocation limits in addition to other measures. I have turned off all
the services I do not need, my broadband modem is placed in standby mode
whenever I do not intend to access the internet, my system is turned off
if I am going to be away from it for any period of time while someone else
has access to the machine.
Now add regular backups on media taken to another location to that and
you can consider your files to be pretty safe. Otherwise hardware
failure or operator error are still your most likely ways to lose
data. Personally I'd take the risk of leaving ssh connections
available from outside if you ever have any reason to need it.
There have been exploits in the past but if you keep your system
updated there should not be much risk now.
