O exec e o shell_exec funcionam aqui? Porque é que nenhuma função do PHP está desactivada

Quem instala uma ferramenta que converte imagens, gera PDF ou corre um comando qualquer à parte acaba por bater nesta pergunta: o exec() funciona no alojamento partilhado? Na maior parte dos fornecedores, não. Aqui, funciona — e a razão por que funciona é mais interessante do que a resposta.

A prática habitual, e porque é que não a seguimos

Quase todos os alojamentos partilhados desligam um conjunto de funções do PHP — system, exec, shell_exec, passthru, proc_open — através de uma lista chamada disable_functions. A ideia é simples: se o PHP não puder correr comandos, um site invadido não corre comandos.

O problema é que essa lista é um remédio para uma doença específica: servidores onde todas as contas partilham o mesmo sistema de ficheiros. Aí, um shell_exec solto podia ir espreitar as pastas dos vizinhos, e a lista negra passa a ser a última defesa. Nunca foi uma boa defesa — é só a que havia.

O que temos em vez disso: uma jaula por conta

Os nossos servidores correm CloudLinux, e cada conta corre dentro de uma jaula própria. Isso muda a natureza do problema: um script seu que corra um comando de sistema só vê a sua conta. Não vê as pastas de outros clientes, não vê a lista de utilizadores do servidor, não alcança a configuração do sistema.

Lista de funções desactivadas Jaula por conta
Proíbe algumas funções Limita o que se consegue ver, qualquer que seja a função usada.
Contorna-se Há sempre outra maneira de correr um comando; a lista negra persegue nomes de funções, não o problema.
Parte software legítimo Não parte nada. As ferramentas que precisam de correr comandos correm.
É a defesa do servidor É a defesa do servidor e a separação entre clientes.

Por isso, aqui, nenhuma função do PHP está desactivada — e não precisa de pedir para activar nada. Se veio de um fornecedor onde tinha de pedir, pode simplesmente usar.

O que isto destrava, na prática

O que passa a funcionar Exemplos do dia a dia
Ferramentas de imagem Conversões e redimensionamentos que chamam o ImageMagick pela linha de comandos, em vez da extensão.
Geração de PDF e documentos Bibliotecas que invocam um binário externo para compor o ficheiro.
Plugins de cópia de segurança Os que usam comandos de sistema para comprimir e exportar bases de dados — costumam ser bastante mais rápidos assim.
Scripts próprios em cron Tarefas agendadas que chamam utilitários — ver que tecnologias correm aqui
Antes de assumir que precisa de um comando. Muita biblioteca traz dois caminhos: um que usa uma extensão do PHP e outro que chama um binário. O primeiro é quase sempre mais rápido e mais previsível. Confirme se a extensão de que precisa está ligada antes de partir para o exec() — ver ver e ajustar a configuração do PHP.

O que a jaula continua a impedir

«Nenhuma função desactivada» não quer dizer «acesso a tudo». Continua a haver limites, e são eles que tornam isto seguro:

1 Só vê os seus ficheiros. Sair da sua conta não é possível, com qualquer função.
2 Só corre os binários permitidos. A jaula tem um conjunto curado de ferramentas — não é o sistema inteiro.
3 Não pode instalar software no sistema. Para isso é um servidor seu — ver alojamento partilhado ou VPS.
4 Os recursos continuam limitados por conta: processador, memória, número de processos e acesso ao disco. Um comando pesado esbarra nesses limites, e não nos vizinhos.
Há dois limites de memória, e confundi-los custa tempo. O memory_limit do PHP é por pedido; o limite da conta é para tudo o que está a correr ao mesmo tempo, incluindo os comandos que o seu script lançar. Subir o primeiro não levanta o segundo — a diferença está explicada em os limites do PHP, e o consumo real vê-se em acompanhar o desempenho no cPanel.

A parte que continua a ser sua

A jaula protege os outros clientes de si, e protege-o a si dos outros. O que ela não faz é protegê-lo de si próprio: um plugin desactualizado com capacidade de correr comandos ainda pode estragar a sua conta. As regras de sempre continuam a valer — ver o que fazemos pela segurança e o que fica do seu lado.

1 Nunca passe para um comando algo que veio do visitante sem o validar. É a forma clássica de transformar um formulário num painel de controlo para outra pessoa.
2 Use as funções de escape da linguagem antes de montar qualquer comando.
3 Mantenha tudo actualizado. Continua a ser a primeira defesa, e por larga margem.

Se desconfiar que alguma coisa já corre no seu espaço sem ser sua, como saber se o seu site foi comprometido tem os sinais; e o registo de erros do PHP costuma ter a primeira pista.

Se precisar de mais do que a jaula permite

Há casos em que o partilhado deixa de servir: instalar um serviço próprio, uma versão compilada à medida, ou algo que fique a ouvir numa porta. Aí o caminho é um servidor só seu, com a liberdade e a responsabilidade que isso traz — ver manter o seu VPS seguro e o que pode alojar aqui. E se o que precisa é só uma porta de saída, isso resolve-se sem mudar de plano: que portas estão abertas.

O seu programador precisa de correr um comando e não tem a certeza?

Pergunte-nos

PRODUTO RECOMENDADO

Alojamento de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 9,00 €/mês

Ver planos
  • 0 Utilizadores acharam útil
Esta resposta foi útil?