[theme-reviewers] File operations in themes, which PHP functions are/will stay allowed?

Otto otto at ottodestruct.com
Tue Apr 5 02:42:43 UTC 2011


If you need to read a local text file, you can still use file() to
read it into an array of strings (one line per array entry).
file_get_contents() is blocked by the theme check mainly because it's
used in the vast majority of theme malware out there. You should also
consider using more specific functionality, like parse_ini_file() to
read in ini files, or fgetcsv() to read CSV files and such. PHP has
several file reading functions specialized for various uses.


If you need to write a local file, then a) you should rethink what
you're doing, since a theme should never need to write to a local
file, and b) if you still want to do it, you should use the
WP_Filesystem functionality. The WP_Filesystem code is capable of both
reading and writing files, and it can do it compatibly, on several
different types of hosting environments.

WP_Filesystem is basically the same thing that plugin/theme/core
updaters use to write files. The downside to using it is that you may
have to include code to ask the user for FTP credentials.

Here's the basic problem with writing files locally: File Ownership.
If you use just a simple file_put_contents or something similar to
create a file, then even assuming you have the permissions to write to
that directory, then the file will be created with its owner set to
the user that the webserver is running as. This can create a security
problem.

Most webservers run as a different user than the normal file owner. So
let's say I'm "otto" and my files are owned by "otto". My webserver
runs as "nobody". When I create a file via that code, the owner of
that file is now "nobody". This is a problem because now that file is
available and *writable* to anybody else running any sort of code on
that same webserver. Because their code runs as "nobody" too. My files
owned by me, "otto", are not writable by the webserver, it can only
read them. So though other people can read and even possibly run my
code from the webserver user, they can't change it.

The WP_Filesystem uses one of several methods available to not only
create files, but to create them as the correct user. On a server
running in an "setuid" mode, then the "direct" method is used, because
the webserver is running as the actual owner of the PHP files. But on
a server running in another mode, such as "nobody", then this file
ownership mismatch is detected and it asks for FTP credentials. Why?
Because it can FTP back to itself and then create files as the
username that it's FTP'ing in as, thus getting the correct file
ownership.

I admit that if you write files a lot, then this can be a pain in the
ass since you may have to prompt the user for FTP credentials. My
advice is to just get over it and do it, because nobody likes their
theme to be easily vulnerable to shared server exploits when run on
non-setuid servers (which, BTW, is the vast majority of them). Best
way is to limit the files you write as much as possible, so as to not
write files too often.

Better way is to not write files at all. Store your data in the
database, where it belongs. Use the set_theme_mod() and
get_theme_mod() functions for storing and retrieving theme settings.
Put dynamic CSS inline in the page using wp_head. Avoid creating files
on demand.


-Otto



On Mon, Apr 4, 2011 at 8:15 PM, Lmm Muc <lmmmuc at gmail.com> wrote:
> Looks like file_get_contents is not permitted anymore. What about fopen
> etc.? Looks like they still can be used?
> What can and cannot be used regarding opening, closing, writing to files?
> I plan to write dynamic CSS to a file (ending on .css) located in the theme
> folder
> Greetings,
> Flynn
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>


More information about the theme-reviewers mailing list