apache 当通过服务器端包含调用 Perl 时，是什么导致了“suexec 策略违规”？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2033726/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What causes "suexec policy violation" when Perl is called via server side include?
提问by Nick Bolton
I'm working on a Perl script which is called from a server side include on an Apache 2 server. The script is displaying the generic "Internal Server Error" page rather than showing me the actual error. When I check the Apache error log, I see these messages:
我正在处理从 Apache 2 服务器上的服务器端调用的 Perl 脚本。该脚本正在显示通用的“内部服务器错误”页面，而不是向我显示实际错误。当我检查 Apache 错误日志时，我看到以下消息：
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/
How do I get a Perl script to show an error rather than "Internal Server Error"?
如何让 Perl 脚本显示错误而不是“内部服务器错误”？
Update:
更新：
I should have asked a separate question for this, because I have since learnt that this doessend errors to the browser (thanks brian):
我应该为此提出一个单独的问题，因为我后来了解到这确实会向浏览器发送错误（感谢 brian）：
use CGI::Carp qw(fatalsToBrowser);
However, if the problem is with the Apache config rather than the Perl script, then the error will not be sent to the browser because the Perl code is not being interpreted. In this case, we can tell that I am experiencing an Apache error (rather than a Perl error) because of this line:
但是，如果问题出在 Apache 配置而不是 Perl 脚本上，那么错误将不会发送到浏览器，因为 Perl 代码没有被解释。在这种情况下，我们可以看出我遇到了 Apache 错误（而不是 Perl 错误），因为这一行：
suexec policy violation: see suexec log for more details
This occurs when Apache is running in SUexec mode (which seems to be common for shared hosting). I'm not sure what exactly has been changed to cause this error, but that's what I'm trying to find out.
当 Apache 在 SUexec 模式下运行时会发生这种情况（这对于共享主机来说似乎很常见）。我不确定导致此错误的确切原因是什么，但这就是我想要找出的。
回答by sorin
回答by brian d foy
Use CGI::Carp's fatalsToBrowser.
使用CGI::Carp的fatalsToBrowser.
use CGI::Carp qw(fatalsToBrowser);
You might also want to see my Troubleshooting Perl CGI scripts.
您可能还想查看我的故障排除 Perl CGI 脚本。
From the error message, I'm guessing that you aren't allowed to execute CGI scripts from server side includes. Which version of your Apache are you running? If it's an old apache, see the suexec docs for apache 1.3, or if it's a newer apache, see the suexec docs for apache 2.0.
从错误消息中，我猜测您不允许从服务器端包含执行 CGI 脚本。您运行的是哪个版本的 Apache？如果它是旧的 apache，请参阅apache 1.3 的 suexec 文档，或者如果它是较新的 apache，请参阅apache 2.0 的 suexec 文档。
回答by atk
It's not for user friendliness, but often for security that we don't show users the exact error when the user can't do anything about it. For example, imagine that a back end server is unavailable. What can I, as a user, do to fix that in your web application?
这不是为了用户友好，而是为了安全，当用户无法做任何事情时，我们不会向用户显示确切的错误。例如，假设后端服务器不可用。作为用户，我可以做些什么来解决您的 Web 应用程序中的问题？
In some cases, error messages will contain useful information, like "SQL Error: illegal syntax. Unmatched ' ". If the user had input a quote in their input, this feedback would indicate a SQL injection vulnerability.
在某些情况下，错误消息将包含有用的信息，例如“SQL 错误：非法语法。不匹配的'”。如果用户在其输入中输入了引号，则此反馈将表明存在 SQL 注入漏洞。
Other benign looking messages are bad to show to users, as well. The key thing that the attacker wants is to know "something different happened." If the application prints out one error for one input,and another error for another iinput, then the attacker knows that something different has gone wrong, and that this is an interesting place to focus.
其他看似良性的消息也不利于向用户显示。攻击者想要知道的关键是“发生了一些不同的事情”。如果应用程序为一个输入打印出一个错误，而为另一个 iinput 打印出另一个错误，那么攻击者就知道出现了不同的问题，这是一个值得关注的有趣地方。
In a production site, errors should be logged to file, and, if appropriate, downloadable through your web interface - but be very careful to sanitize any output to the browser to avoid cross site scripting. And there should be no user-submitted option to reconfigure this between debug and production (don't control it via a POST or CGI parameter, but by a configuration file option).
在生产站点中，应该将错误记录到文件中，并且如果合适，可以通过您的 Web 界面下载 - 但要非常小心地清理浏览器的任何输出，以避免跨站点脚本。并且不应该有用户提交的选项来在调试和生产之间重新配置它（不要通过 POST 或 CGI 参数控制它，而是通过配置文件选项）。
回答by Boris Ivanov
This could be 3 factors:
这可能是 3 个因素：
- Permissions level rwx set wrong (execution/writeness level)
- UUID/GUID do not match Apache settings
- Combination of 2 above.
- 权限级别 rwx 设置错误（执行/写入级别）
- UUID/GUID 与 Apache 设置不匹配
- 以上2的组合。
Check apache suexec+errorlog for details
查看 apache suexec+errorlog 了解详情
