Systemcrash suexec forkbomb.sh ulimits

1

Eu recebi este script chamado fork.sh:

#!/bin/sh
forkbomb() { forkbomb | forkbomb & } ; forkbomb

Se eu ligar através do suexec, todo o meu sistema consumirá 99% de CPU. Para evitar um forkbomb normal bash eu usei o limits.conf e set nproc para 50. Isso funciona como esperado.

Mas se eu chamar o script acima mencionado através do suexec através do httpd, vejo no topo mais de 6000 tarefas e uma CPU do sistema usa > 97%. Eu posso ver várias entradas de user3 fork.sh com ~ 0,6% cpu. Se eu chamo systemd-cgtop o system.slice tem 100% cpu e system.slice / httpd.service 75%

Eu restrinjai o httpd com cgroups:

 systemctl set-property --runtime httpd.service CPUShares=600 MemoryLimit=500M 

Eu não entendi, porque ulimits e cgroups não vão lidar com esse problema.

    
por bubele 02.06.2015 / 10:19

1 resposta

0

Os arquivos limits são utilizados por PAM . O estoque suexec fornecido pelo apache ainda não reconhece ou utiliza PAM . Existem patches. E você pode modificar a fonte diretamente para invocar setrlimit (parece bem fácil - veja a página setlimit(2) man.) Mas como está, suexec não reconhecerá nada que você fizer com limits .

Você ainda pode configurar ulimits de dentro do apache, mas acho que isso é indesejável, especialmente no modelo de pré-fork, porque então você limita a carga que seu servidor http pode manipular. Além disso, não tenho certeza se os limites serão transferidos para o ambiente suexec porque não sei como suexec faz seu trabalho.

O motivo CPUShares não o ajudará aqui é porque a sua fork é um "resource hog", mas os recursos não estão realmente nos ciclos da CPU. Quando a contabilização da CPU se torna envolvida, é tarde demais: o sistema não tem memória livre ou slots de processo para tentar executar o programa.

Você pode experimentar prlimit , parte de util-linux , por isso deve ser padrão em sua instalação. Se você fizer isso:

$ prlimit --nproc=1 bash -c bash -c id

bash: fork: retry: No child processes

Portanto, o pequeno processo de 2-fork falhou.

Infelizmente, não vejo uma boa maneira de se envolver na cadeia de execução. O Apache se autocentrou e a todos nós, fornecendo um módulo suexec reprovado que não é flexível o suficiente para atender à demanda básica, e é simples o suficiente para que qualquer solução real exija um buraco na segurança.

    
por 02.06.2015 / 11:35