:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:>    Give me a shell and I can crash any machine.  If you are assuming
:>    hostile users, you cannot assume that your magic overcommit protection
:>    will save your server.  Saying that the kernel and application behave
:>    properly is a cop-out, because it's virtually impossible to guarentee
:>    that for every situation.  The chance of a user blowing up the server
:>    by finding a bug or a hole somewhere is much, much greater then the chance
:>    of a user running the system out of swap.  
:
:If you are trying to say that it is easier to crash FreeBSD than
:the system out of swap. You might be wrong.
:
:Memory consumption is quite easy, almost every programmer can do it
:with normal user privilege.
:If there is a bug which crashes FreeBSD and which is easier to write
:than memory consumption, it is better to fix the bug.
:--
:soda

    It's a lot harder then you think.  Again, taking my BEST experience...
    the shell machines had 128MB to 512MB of ram and usually on the order
    of a gig of swap.  Being shell machines we had our share of IRC hackers.

    We could always tell when there were no root holes on the systems because
    the IRC hackers would get into an account (users often logged in from
    public libraries or other unsecure locations and got their passwords
    sniffed)..  Where was I?  Oh yah, the IRC hackers would get into an
    account, try all their root tricks and fail, then get frustrated and
    attempt to crash the machine from the user's account.

    They were *never* able to run our machines out of swap.  They could make
    them page heavily, but they could never run them out of swap.  Before
    they even got swap 20% full the load would come to the attention of a
    sysop who would stare bemusedly at the idiot IRC hacker, then send him
    a few snide remarks with write before disabling the account and killing 
    the processes.

    On the otherhand, there are a number of known ways to crash a FreeBSD
    box that do not involve running it out of stack.  The most interesting
    one that I know of is with a spoofed-packet attack that randomizes
    the source IP.  FreeBSD builds up temporary route table entries for
    the return packet and panics with a kernel memory limit being hit on
    the route table.  Or I should say it used to.  I've fixed that little
    problem.

    There are other ways.  For example, even if a user account is resource
    limited, root processes (such as sendmail, popper, identd, and so forth)
    are not.  Attacks against these servers generally result in very high
    loads and sometimes make it difficult to login to fix the problem, but do
    not result in running out of swap.

    With today's modern high capacity disk drives, a properly configured
    multi-user system will have enough swap that running it out is difficult
    to say the least.  Even my home server has 512MB of swap and could
    easily have several gigabytes if I thought it necessary.  We always 
    recommend that you allocate swap sufficient for your needs - usually
    2xMEM.  But the word "sufficient" can also mean to allocate extra swap
    if you believe that the runaways are common enough to cause a problem.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>