You might want to familiarize yourself with ulimits. Alex Brodsky wrote: > Hi, > > The following is a known issue, from at least 2002, but I am not sure > how it was resolved. > > Problem: The default configuration of OpenBSD allows any user to > incapacitate the machine by exhausting the kernel's file descriptor > (FD) table. > > By default the kernel allocates 1772 FDs (kern.maxfiles). OpenBSD > allows limits to be placed on the number of FDs a process can use and > the number of processes a user can run. Hence, the number of FDs that > a user can allocated is max_processes x max_num_fds_per_proc, which > greatly exceeds 1772. > > When all FDs are used up, not new process can be created, no one can > log in, and no files can be opened by running processes. That is, > unless the offending processes are killed, the system has to be > rebooted, which cannot necessarily be done in a clean manner if no one > else can log in. > > While the brute-force solution is to simply increase the size of the > kernel's FD table, I am more interested in the rationale behind the > present default configuration. > > Namely, > > 1) If a user can bring down the entire system in its default > configuration, is it reasonable to call the system ``secure''? > > 2) To whom should I direct this query? > > 3) Apart from increasing the size of the FD table, further limiting > the number of processes that users may run, and further limiting the > the number of FDs a process may allocate, what other measures can be > taken to avoid this issue? > > As an aside, I experienced this DoS problem first hand due to a bug in > a the Dovecot IMAP server 1.0-beta3.
