fopen bacame a 'fail' over 3 months ago<div><br></div><div>As Otto mentioned there are several alternatives, Phil found one for reading a file in, to write files you will have to use wp_filesystem, it isnt that hard really.<br>
<br><div class="gmail_quote">On 24 June 2011 22:44, Philip M. Hofer (Frumph) <span dir="ltr"><<a href="mailto:philip@frumph.net">philip@frumph.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I got around fopen by using file() instead and imploding it (thanks otto and pross for the idea)<br>
<br>
<br>
<br>
function comicpress_display_comic_text(<u></u>$comic) {<br>
$output = '';<br>
if (file_exists(comicpress_<u></u>themeinfo('basedir') . '/' .$comic)) {<br>
$output = implode('', file(comicpress_themeinfo('<u></u>basedir') . '/' .$comic));<br>
}<br>
return apply_filters('comicpress_<u></u>display_comic_text', $output);<br>
}<br>
<br>
<br>
<br>
-----Original Message----- From: Otto<br>
Sent: Friday, June 24, 2011 2:38 PM<br>
To: <a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
Subject: Re: [theme-reviewers] Theme submission fails on WARNING<div><div></div><div class="h5"><br>
<br>
On Fri, Jun 24, 2011 at 4:14 PM, Bruce Wampler <<a href="mailto:brucewampler@gmail.com" target="_blank">brucewampler@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To my shock, the latest version of the theme was rejected by the standard<br>
upload process with only one WARNING. In the past, WARNINGS were just that -<br>
something that need further review before approval. Now apparently, WARNINGS<br>
cause automatic rejection.<br>
</blockquote>
<br>
Yes, we decided to turn the screw a bit harder a few months ago. The<br>
major elements of the theme check is now a required pass for<br>
uploading.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the only WARNING issued by the submission process for fopen.<br>
...<br>
There are no security issues with the way Weaver uses file<br>
operations.<br>
...<br>
have you really banned fopen?<br>
</blockquote>
<br>
Yes, fopen, and other direct file operations, are banned. Writing<br>
files from the theme (or from a plugin) in the most direct manner is<br>
inherently insecure on quite a number of shared hosting environments.<br>
<br>
I go into this in more detail here:<br>
<a href="http://ottopress.com/2011/tutorial-using-the-wp_filesystem/" target="_blank">http://ottopress.com/2011/<u></u>tutorial-using-the-wp_<u></u>filesystem/</a> but I'll<br>
give you the quick version.<br>
<br>
As you're a PhD and a software developer, I'll assume you understand<br>
UNIX file ownership and process permissions and such. In your typical<br>
shared hosting environment, several users all have directories for<br>
their website files. These files are owned by the user account. The<br>
web process (let's say apache), runs as a different, unprivileged user<br>
(lets say "nobody").<br>
<br>
When the PHP code is executing, it's executing with the credentials of<br>
that nobody user. So when it makes files, the resulting files are<br>
owned by "nobody".<br>
<br>
Here's the problem: If the files are owned by the apache process, then<br>
anybody else who can get that apache process to execute their code can<br>
write to those files, by simply writing code that writes to them then<br>
running it on their own websites. Since we're in a shared hosting<br>
environment, everybody else on that web server now has the ability, by<br>
writing code on their own websites, to modify the files of somebody<br>
else's website on the same server. This works irrespective of normal<br>
600 type permissions, because the process writing to the files<br>
(nobody) is the same one that owns the files (nobody).<br>
<br>
Writing files as nobody also introduces problems on some hosts where<br>
the user themselves find they can't delete or modify files in their<br>
own directory without doing it through the webserver process.<br>
<br>
And if other users can write files that are used on your website, even<br>
if they're only CSS files, then that's a rather obvious security<br>
problem. With just CSS I can still inject javascript code into your<br>
site and steal your credentials and so on.<br>
<br>
The solution is that files should be owned by the user's own account,<br>
not by the apache process.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you really want to take away advanced<br>
features that require it from WordPress users?<br>
</blockquote>
<br>
Not at all. There are alternative methods, although they have drawbacks.<br>
<br>
When WordPress self-upgrades, it goes to pains to make sure that not<br>
only can it create and write files, but that the resulting files are<br>
owned by the correct user account and not by some other user account.<br>
It uses one of five or so methods to write files, depending on the<br>
server configuration. This is all packaged up into the WP_Filesystem<br>
classes and there are methods for using it which I detailed on my<br>
blog: <a href="http://ottopress.com/2011/tutorial-using-the-wp_filesystem/" target="_blank">http://ottopress.com/2011/<u></u>tutorial-using-the-wp_<u></u>filesystem/</a><br>
<br>
The drawback is that whenever you have to write files, you sometimes<br>
(depending on the server configuration) have to ask the user for their<br>
FTP credentials, so that it can write files via that loopback method,<br>
thus creating files as the user instead of creating them as the<br>
webserver process. If the servers are configured using the setuid<br>
method (where the PHP process changes its user to be the user of the<br>
owner of the PHP files), then the "direct" method is used by the<br>
WP_Filesystem, and no credentials are required. This is actually safer<br>
in shared hosting, and becoming more and more common. Even cheap<br>
GoDaddy hosting uses setuid methods.<br>
<br>
This may require a rethinking of your file writing operations and/or<br>
your interface, but in the end, it's worth it for security reasons.<br>
<br>
-Otto<br>
______________________________<u></u>_________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/<u></u>mailman/listinfo/theme-<u></u>reviewers</a> <br>
______________________________<u></u>_________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org" target="_blank">theme-reviewers@lists.<u></u>wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/<u></u>mailman/listinfo/theme-<u></u>reviewers</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>My Blog: <a href="http://www.pross.org.uk/">http://www.pross.org.uk/</a><br>Plugins : <a href="http://www.pross.org.uk/plugins/">http://www.pross.org.uk/plugins/</a><br>
Themes: <a href="http://wordpress.org/extend/themes/profile/pross">http://wordpress.org/extend/themes/profile/pross</a><br>
</div>