O que causa “violação da política de Suexec” quando o Perl é chamado por meio do lado do servidor?

Question

Estou trabalhando em um script PERL chamado de um lado do servidor incluir em um servidor Apache 2. O script está exibindo a página genérica de "erro interno do servidor", em vez de me mostrar o erro real. Quando verifico o log de erros do Apache, vejo essas mensagens:

unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/

Como faço para obter um script Perl para mostrar um erro em vez de "erro interno do servidor"?

Atualizar:

Eu deveria ter feito uma pergunta separada para isso, porque já aprendi que isso faz Envie erros para o navegador (Obrigado Brian):

use CGI::Carp qw(fatalsToBrowser);

No entanto, se o problema estiver com a configuração do Apache, em vez do script Perl, o erro não será enviado ao navegador porque o código PERL não está sendo interpretado. Nesse caso, podemos dizer que estou experimentando um erro do Apache (em vez de um erro Perl) por causa dessa linha:

 suexec policy violation: see suexec log for more details

Isso ocorre quando o Apache está em execução no modo SUEXEC (que parece ser comum para hospedagem compartilhada). Não tenho certeza do que exatamente foi alterado para causar esse erro, mas é isso que estou tentando descobrir.

Answer 1

Provavelmente você está usando hospedagem compartilhada e tem esse problema porque seu diretório de scripts ou o Arquivo de script tem outros direitos além 755.

Aqui está um caso traduzido de holandês.

Answer 2

Usar CGI :: Carp's fatalsToBrowser.

 use CGI::Carp qw(fatalsToBrowser);

Você também pode querer ver meu Solução de problemas de scripts perl cGI.

A partir da mensagem de erro, acho que você não tem permissão para executar scripts CGI do lado do servidor. Qual versão do seu Apache você está executando? Se for um Apache antigo, veja Os documentos SUEXEC para Apache 1.3, ou se for um Apache mais novo, veja Os documentos SUEXEC para Apache 2.0.

Answer 3

Não é para facilidade de uso do usuário, mas geralmente para a segurança que não mostramos aos usuários o erro exato quando o usuário não pode fazer nada a respeito. Por exemplo, imagine que um servidor de back -end não está disponível. O que posso, como usuário, fazer para corrigir isso no seu aplicativo da Web?

Em alguns casos, as mensagens de erro conterão informações úteis, como "Erro SQL: sintaxe ilegal. Incomitada '". Se o usuário tivesse inserido uma cotação em sua entrada, esse feedback indicaria uma vulnerabilidade de injeção de SQL.

Outras mensagens de aparência benigna também são ruins para mostrar aos usuários. A principal coisa que o atacante deseja é saber "algo diferente aconteceu". Se o aplicativo imprime um erro para uma entrada e outro erro para outro iInput, o atacante sabe que algo diferente deu errado e que este é um lugar interessante para se concentrar.

Em um site de produção, os erros devem ser registrados no arquivo e, se apropriado, download através da interface da Web - mas tenha muito cuidado para higientar qualquer saída no navegador para evitar scripts de site cruzado. E não deve haver opção substituída pelo usuário para reconfigurar isso entre depuração e produção (não o controlasse por meio de um parâmetro post ou CGI, mas por uma opção de arquivo de configuração).

Answer 4

Isso pode ser 3 fatores:

1. Nível de permissões RWX Conjunto errado (nível de execução/escrita)
2. UUID/GUID não corresponde às configurações do Apache
3. Combinação de 2 acima.

Verifique o Apache Suexec+ErrorLog para obter detalhes