<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">PHP-FPM allows generating its own log files.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The default behavior of having errors sent back the FastCGI tube can be overridden with proper error logging on PHP-FPM side.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">2048 bytes for each line of log is more than enough on the web server side.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Do your homework: read the PHP docs. If you are still struggling, ask some PHP community to help you through.<br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Wed, Jun 15, 2016 at 5:53 PM, Robert Paprocki <span dir="ltr"><<a href="mailto:rpaprocki@fearnothingproductions.net" target="_blank">rpaprocki@fearnothingproductions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you're allowing user-generated output to be written directly to your logs without any sort of sanitation, you've got bigger problems to worry about :p  Again, it doesn't really make sense to have your fcgi error sent here- why can't your fcgi process log elsewhere, and leaving the nginx error log for nginx issues?</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 6:51 AM, philipp <span dir="ltr"><<a href="mailto:nginx-forum@forum.nginx.org" target="_blank">nginx-forum@forum.nginx.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm I understand that limitation. But an attacker or a bad application can<br>
hide the important information which we need to identify the source of the<br>
problem.<br>
<br>
What about limiting the fastcgi output to 1024 bytes and appending this info<br>
with max 1024 bytes.<br>
client: 127.0.0.1, server: <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>, upstream:<br>
"fastcgi://unix:/var/run/php-fpm-example.com.sock:", host: "127.0.0.1" ,<br>
request: "GET / HTTP/1.1"<br>
<br>
[fastcgi - output max 1024][request info: client, server, upstream, host,<br>
request - max 1024]<br>
<br>
This would ensure that client, server and upstream are always provided. Host<br>
and Request can be filled with "user generated" content, so you should put<br>
it to the end. This would ensure that an attacker cannot hide the important<br>
fields.<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,267568,267592#msg-267592" rel="noreferrer" target="_blank">https://forum.nginx.org/read.php?2,267568,267592#msg-267592</a><br>
<div><div><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br></blockquote></div><br></div></div>