是什么原因导致“suexec 策略违规”？当通过服务器端包含调用 Perl 时？
我正在编写一个 Perl 脚本，该脚本从 Apache 2 服务器上的服务器端调用。该脚本显示通用的“内部服务器错误”页面，而不是向我显示实际的错误。当我检查 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/
如何让 Perl 脚本显示错误而不是“内部服务器错误”？
更新：
我应该为此提出一个单独的问题，因为我已经了解到这确实会向浏览器发送错误（谢谢 brian)：
use CGI::Carp qw(fatalsToBrowser);
但是，如果问题出在 Apache 配置上与 Perl 脚本相比，则错误不会发送到浏览器，因为 Perl 代码没有被解释。在这种情况下，我们可以看出，由于这一行，我遇到了 Apache 错误（而不是 Perl 错误）：
suexec policy violation: see suexec log for more details
This indicates when Apache is running in SUexec mode (这对于共享主机来说似乎很常见)。我不确定到底是什么发生了变化导致了这个错误，但这就是我想要找出的。
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:
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"?
Update:
I should have asked a separate question for this, because I have since learnt that this does send errors to the browser (thanks 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:
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能正在使用共享主机，并且遇到此问题是因为您的脚本目录或脚本文件确实拥有除
755之外的其他权限。这是一个 case 从荷兰语翻译而来。
Probably you are using shared hosting and you have this problem because your scripts directory or the script file does have other rights than
755.Here is one case translated from Dutch.
使用 CGI::Carp 的
fatalsToBrowser。您可能还想查看我的Perl CGI 脚本故障排除。
从错误消息来看，我猜测您不允许从服务器端包含执行 CGI 脚本。您运行的是哪个版本的 Apache？如果是旧版 apache，请参阅 apache 1.3 的 suexec 文档，或者如果它是较新的 apache，请参阅 apache 2.0 的 suexec 文档。
Use CGI::Carp's
fatalsToBrowser.You might also want to see my Troubleshooting Perl CGI scripts.
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.
这不是为了用户友好，而是为了安全，当用户无能为力时，我们不会向用户显示确切的错误。例如，假设后端服务器不可用。作为用户，我可以做什么来解决您的 Web 应用程序中的问题？
在某些情况下，错误消息将包含有用的信息，例如“SQL错误：非法语法。不匹配'”。如果用户在输入中输入了引号，则此反馈将表明存在 SQL 注入漏洞。
其他看似良性的消息也很难向用户展示。攻击者想要的关键是知道“发生了不同的事情”。如果应用程序为一个输入打印出一个错误，并为另一个输入打印出另一个错误，那么攻击者就知道出现了不同的问题，并且这是一个值得关注的有趣地方。
在生产站点中，错误应该记录到文件中，并且如果合适，可以通过 Web 界面下载 - 但要非常小心地清理浏览器的任何输出，以避免跨站点脚本编写。并且不应该有用户提交的选项来在调试和生产之间重新配置它（不要通过 POST 或 CGI 参数控制它，而是通过配置文件选项控制它）。
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?
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.
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.
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).
这可能是 3 个因素：
检查 apache suexec+errorlog 了解详细信息
This could be 3 factors:
Check apache suexec+errorlog for details