If you were to globally set

alias ':(){ :|:& };:'='echo fork bomb averted'

would that be an effective security strategy to avoid the Bash fork bomb execution or would there still be a way to execute it?

I suppose the question cashes out to: is there a way to execute a command when it's aliased to something else?

  • 1
    @user1717828, a "fork bomb" is a program that simply runs new copies of itself, forever. The resulting exponential growth in the number of programs running usually causes something to break in short order.
    – Mark
    Aug 28, 2018 at 21:18
  • 1
    Even if this did work - it wouldn't protect against a program that calls fork() not going through bash?
    – UKMonkey
    Aug 29, 2018 at 9:20
  • 2
    – Joshua
    Aug 29, 2018 at 17:25
  • 3
    Just run a(){ a|a& };a
    – user253751
    Aug 29, 2018 at 23:12
  • 1
    You'd avoid the common form (if you'd get it to work at all), but there's a near infinite amount of variations on it possible.
    – Mast
    Aug 30, 2018 at 7:33

4 Answers 4


The two, no, three, ... Amongst the main obstacles to that are:

  1. It's not a valid name for an alias. Bash's online manual:

    The characters ... and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

    (, ), &, | and whitespace are out in Bash 4.4.

  2. That particular string is not the only way to write a fork bomb in the shell, just famous because it looks obscure. For example, there's no need to call the function : instead of something actually composed of letters.

  3. If you could set the alias, the user could unset the alias, circumvent it by escaping the alias name on the command line, or disable aliases altogether, possibly by running the function in a script (Bash doesn't expand aliases in noninteractive shells).

  4. Even if the shell is restricted enough to stop all versions of a fork bomb, a general purpose system will have other programmable utilities that can recurse and fork off subprocesses. Got Perl or a C compiler? Easy enough. Even awk could probably do it. Even if you don't have those installed, you'll also need to stop the user from bringing in compiled binaries from outside the system, or running /bin/sh which probably needs to be a fully operational shell for the rest of the system to function.

Just use ulimit -u (i.e. RLIMIT_NPROC) or equivalent to restrict the number of processes a user can start. On most Linux systems there's pam_limits that can set the process count limit before any commands chosen by the user are started.

Something like this in /etc/security/limits.conf would put a hard limit of 50 processes to all users:

*        hard    nproc           50

(Stephen Kitt already mentioned point 1, Jeff Schaller mentioned 2 and 3.)

  • Is it possible to write a fork bomb without &? Aug 28, 2018 at 14:51
  • 4
    @StephenKitt I am not 100% sure but my guess is that bash is turing complete. If so there are likely infinite possibilities. For example you could parse ascii char-code 38 and execute it.
    – Marie
    Aug 28, 2018 at 16:57
  • @Marie in this particular context you’d also have to avoid any of the other forbidden characters while working around the & limitation. Aug 28, 2018 at 17:30
  • 15
    My point was mainly that trying to blacklist bad functionality is a bad idea. There are almost always ways around.
    – Marie
    Aug 28, 2018 at 17:32
  • 2
    @Marie: Bash is quite certainly Turing complete. Aug 29, 2018 at 20:58

No. There are just too many ways to write a fork-bomb.

The evil fork-bomb writer will just try again with a different function name. Or other alterations until his fork-bomb succeeds.

The inadvertent fork-bomb writer won't produce the canonical fork-bomb in the first place.

It's actually rather easy to become an inadvertent fork-bomb writer yourself. For instance, you could just use recursive make with an external, unchecked cd, combining it with the -j option and non-existing subdirectories -- a real example I've stumbled upon once.

You cannot safeguard against all possibilities, and most certainly not against a determined attacker. All you will achieve is to increase the complexity of your system.


You can’t alias a fork bomb, because it’s not a valid alias name:

$ alias ':(){ :|:& };:'='echo fork bomb averted'
bash: alias: `:(){ :|:& };:': invalid alias name

The characters ‘/’, ‘$’, ‘`’, ‘=’ and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

Some shells don’t check alias names when they’re declared, but when interpreting commands, and skip the invalid name then. A fork bomb will always include &, which can’t be included in a valid alias name, so protecting yourself in this way isn’t possible.

  • Whether a shell permits to set up this alias or not does not matter. Important is that even iff such an alias exists, it is not expanded while interpreting commands since the alias name does not match the permitted pattern. dash and bosh e.g. both silently ignore it.
    – schily
    Aug 28, 2018 at 13:46

Twice, no.

That's not the only way to write a fork-bomb.

There's also several ways to execute "a command" when there's an alias:

command the-command


$ alias ls=not-really-ls
$ ls
-bash: not-really-ls: command not found
$ \ls
jeff.html  output.png
$ command ls
jeff.html  output.png
  • Not related to main topic but why did \ls show output.png but command ls didn't?
    – nxnev
    Aug 31, 2018 at 11:34
  • Well-spotted! That is, indeed, unrelated to the main topic. It's a classic PEBCAK error where I copy/mis-pasted (or cleaned up the output.png in-between). I'll fix it to minimize distractions. Thank you, @nxnev!
    – Jeff Schaller
    Aug 31, 2018 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .