Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is the standard question, "How do I set a process limit for a user account in Linux to prevent fork-bombing," with an additional twist. The running program originates as a root-owned Python process, which then setuids/setgids itself as a regular user. As far as I know, at this point, any limits set in /etc/security/limits.conf do not apply; the setuid-ed process may now fork bomb. Any ideas how to prevent this?

share|improve this question

migrated from Mar 12 '10 at 10:41

This question came from our site for professional and enthusiast programmers.

Have you also tried setreuid()? Regards – Giuseppe Guerrini Mar 12 '10 at 9:11
Yes, I have tried setreuid(). – BrainCore Mar 12 '10 at 9:15

You need to have a look at "Advanced Programming in the UNIX Environment". This book details the necessary steps to help you achieve that which you are trying. Any child cloned/forked from a process will inherit the parent's rlimits. You have two options here as I see it: one you can specifically set the rlimits after the child is created (not as nice) or you can do the double fork magic to create a new process group and session leader which will properly inherit the rlimits set in the system.

share|improve this answer

Since the child processes inherit the ulimit settings, could you run ulimit in the python script after it sets the uid/gid, creating a new (lower) hard limit, which would then be the new running condition for all of the potential fork-bomblets?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.