WordPress.org

1. leonardjo
   Member
   Posted 2 years ago #
   

   I was very unpleasantly surprised to see that I was asked for filesystem credentials to install a theme on my test installation of WordPress. Who came up with this terrible idea?

   Any permissions you need to install themes, plugins and updates can be supplied at the webserver level. If the user can supply the application with filesystem credentials he's in the position to change file system permissions in such a way that the application can install any file it needs. Technically there is absolutely no need to supply the application with filesystem credentials to install files in the webroot it already has access to.

   Even if you argue that supplying filesystem credentials makes the installation slightly easier than telling the user to (temporarily) make installation files or directories writable this is still sending the wrong message: That it is acceptable to supply your credentials to untrusted applications whenever they ask for it. And yes, I say "untrusted" as it is unclear what kind of booby trap any of the php files of which the hundreds of themes consist contain. You should be using html templates with placeholders to avoid your application from being booby trapped by untrusted third party additions. The approach of using php files in templates makes them just as dangerous as plugins, a fact that many users might not realize.

   In short, in my opinion any code asking for filesystem credentials should be ripped out and reworked so it informs the user which filesystem permissions need to be temporarily set to complete installation of themes, plugins or updates. This can even be semi automated by writing out scripts the user can use to set and unset these file permissions.

   Such instructions should refrain from asking the user to set file permissions to 666 and directory permissions to 777. To write files apache uses either the uid or gid, it never needs world write permissions to touch any file. And in setgid setups as I use them instructing users to chmod directories to 777 then back to 755 or 555 causes serious breakage as now suddenly files will be created with the wrong gid. So instructions/scripts should use instructions like "chmod ug+w" and never absolute file permissions.

2. Samuel Wood (Otto)
   Tech Ninja
   Posted 2 years ago #
   

   Firstly, it actually does check to see that it has access to the webroot with the proper owner and group permissions first. If it has that access, then it uses the "direct" method of upgrading/installing files and will not ask you for any form of credentials. A system configured to run the PHP process as setuid will generally already be running under the correct user, and so it will use this direct mode. For shared servers, a setuid setup is considered to be far more secure.

   So if it does ask you for credentials, then that's because it really does need them. Many hosts have the webserver process running under a different user (like "apache" or "nobody" or what have you), and so it might be unable to create files in your directory and so forth.

   Secondly, if you want to supply those credentials in a config file on the server itself, so that it doesn't ask you, this is an option. Just define FTP_HOST, FTP_USER, and FTP_PASS in the wp-config.php file. It will use these to connect back to itself and modify the files, thus getting the correct owner/group on them.

   Thirdly, an HTML template system is not as flexible as PHP code, and themes do more than just determine how things display on the page. Admittedly, trust is an issue, which is why we have a theme review team here on WordPress.org, which goes through all theme uploads with a fine toothed comb.

3. Samuel Wood (Otto)
   Tech Ninja
   Posted 2 years ago #
   

   For reference, the WordPress filesystem API actually has four different ways of modifying and accessing files on the server. It tests each of them to make sure that any files it creates will have the proper file owner and group settings.

   The direct method just modifies the files directly. This only works on setuid servers, basically, but it is quite commonplace for shared servers to be setup in this way. Easy way to test this method on your own server is to use mod_suphp instead of mod_php.

   The second method uses ssh to connect back to the server. It only works if the ssh php extension is installed, and it requires a bit of setup to work properly.

   The third and fourth methods are different ways of doing FTP, and they can use SSL FTP if it's available.

4. leonardjo
   Member
   Posted 2 years ago #
   

   So if it does ask you for credentials, then that's because it really does need them.

   Secondly, if you want to supply those credentials in a config file

   On the contrary, I do not want, nor is it necessary for any web application to use file system access via an external login. It's all a matter of configuration of the webserver. If you can't make file uploads to work then your hoster is doing a pretty bad job. No excuse to fall back to (S)FTP.

   Also, the application never indicated it needs write permissions to certain locations. It just falls back to asking me for file system credentials instead of educating me on how to fix things.

   Many hosts have the webserver process running under a different user (like "apache" or "nobody" or what have you), and so it might be unable to create files in your directory and so forth.

   This is a nonsense argument. With the right directory permissions apache should be able to write anywhere in the web root. If your setup requires you to chmod 777 upload directories you should be complaining to your hoster, but it should work.

   Thirdly, an HTML template system is not as flexible as PHP code

   You can use placeholders to provide php functions, something like {GET_HEADER} instead of <?php get_header();?> . This way you can provide the theme builders with a lot of flexibility without exposing the full php API.

   Admittedly, trust is an issue, which is why we have a theme review team here on WordPress.org, which goes through all theme uploads with a fine toothed comb.

   Ok, that's good to hear.

5. Samuel Wood (Otto)
   Tech Ninja
   Posted 2 years ago #
   

   On the contrary, I do not want, nor is it necessary for any web application to use file system access via an external login. It's all a matter of configuration of the webserver. If you can't make file uploads to work then your hoster is doing a pretty bad job. No excuse to fall back to (S)FTP.

   It's not a matter of file uploads. It's a matter of it being capable of replacing the files and having the file replacements have the same user and group ownership. That's why it needs credentials, because a process cannot magically create files in somebody else's name.

   Also, the application never indicated it needs write permissions to certain locations. It just falls back to asking me for file system credentials instead of educating me on how to fix things.

   There's nothing to "fix". It's not a matter of a broken system, it's a matter of doing things the right way.

   The application doesn't need "write" permissions. It needs to write files *as you*. With those files owned by you. Since it's not running as you, since it doesn't have the ability to pretend to be you, then it needs your credentials in order to become you and to write those files as you.

   This is a nonsense argument. With the right directory permissions apache should be able to write anywhere in the web root. If your setup requires you to chmod 777 upload directories you should be complaining to your hoster, but it should work.

   No, it's not nonsense.

   Sure, the PHP process running under Apache can create a file. But that file will probably be owned by "nobody" in most normal setups. And it really annoys people when they can no longer access files in their directories via FTP and such.

   Sure, you could tell the user to go login and do a bunch of chown and chgrp stuff to fix all those files... if they know how to do that, or if they even have shell access (which many hosts do not provide). And that assumes that they even have the ability to change ownership of those files, which in a secure setup they will not have.

   You can use placeholders to provide php functions, something like {GET_HEADER} instead of <?php get_header();?> . This way you can provide the theme builders with a lot of flexibility without exposing the full php API.

   You're suffering from the Yet-Another-Format syndrome. Why invent a whole templating system when you can just let theme authors use PHP and be done with it? Do you not trust theme authors? Do you not think that theme authors should be able to do advanced things?

   Many themes do highly advanced things, and often have control panels of their own in the admin interface. Use of PHP allows them to do that. This is by design.

Topic Closed

This topic has been closed to new replies.