I just read a paper about Local File Inclusion on exploit-db.com, it can be found here. One technique with LFI is log poisoning as you may know already. You do an HTTP GET request that contains PHP code. Since it's not a correct HTTP request it gets logged in the apache error.log. Now the attacker can execute the PHP code within the error.log by doing something like http://victim.com/include.php?file=../../../../var/log/apache2/error.log. Now what I don't understand is thefollowing: logs by default are not world readable, so www-data who owns the apache2 process is not able to read error.log and so cannot execute the code within it! How can a log poisoning attack be successful then??
Perfectly legal and smart attack.
You're question really boils down to "how does this work when logs are by default not readable by the webserver?".
The fact is that many webservers are set up with custom log directories where the access control is not necessary enforced. This happesn more often than you would think. In some cases the access control for the log files is wide open because sysadmin needed some other system to read them, and he just opened it up for all processes.
This can also be used to execute code from other log files like from the SSH auth log. More on this here: http://lanmaster53.com/2011/05/local-file-inclusion-to-remote-command-execution-using-ssh/
Basically it boils down to wrong permissions on the files. Even so its a good attack which is very relevant.