On bugtraq is a thread going about "Shared memory DoS's" affecting most
flavors.
I guess this is also important to our port?!

It started with this:
>While fiddling with various IPC mechanisms and reading The Design and
>Implementation of 4.4BSD (What a book!), a few things struch me as potentially
>dangerous. According to the book, when you request a shared memory segment via
>mmap(), the file isn't actually physically in memory until you start to
>trigger page faults and cause the vnode-pager to page in the data from the
>file.
>
>Then, the following passage from shmctl(2) under Linux caught my eye:
>"The user must ensure that a segment is eventually destroyed; otherwise
>its  pages
>that were faulted in will remain in memory or swap."
>
>So as it turns out that it is in fact possible to create a DoS condition by
>requesting a truckload of shared mem, then triggering pagefaults in the entire
>shared region.
>
>Now the end result is no different than a simple fork or malloc bomb, but
>it is
>considerably harder to prevent on most systems.

Very small part of the latest:
>"if you're BSD and have kernel source, checking sys/vm/vm_mmap.c for RLIMIT
>other than STACK should let you know. The proper way to fix this is to have a
>seperate limit for address space or virtual memory. Solaris has both (probably
>since their malloc uses both brk and mmap, and the virtual memory limit is for
>stopping malloc bombs)."


Anyway, in case you developers don't have the posts but do want them, just
let me know and i'll redirect the thread to you.

Have a peacefull weekend,
T@W