Search

Symphony allows to set the file write mode during installation or in the config file. I am not sure about which files are influenced by this setting. Does it only apply to config and .htaccess files? Or does this setting affect any file (even uploaded files)?

I know there have already been some discussions about security implementations of even the default "775" setting. But: In standard webhosting environments often the PHP user and the FTP user will not even belong to the same group. This means changing for example the config file via FTP will require "777" rights for this file.

(Another, rather impractical way is to use a browser-based PHP file viewer/editor - but having something like this on your webspace does definitely weaken security.)

As far as I remember, the installer in Symphony 1.7 had a "777" default setting for files. So maybe someone can help me: Is it really such a big security problem to set the file write mode to "777"? At least for the config file this seems to be the standard solution in PHP systems. So which files are affected by Symphony's setting?

I still have an old 1.7 running where I lowered the permissions (by looong trial and error) after being hacked once, and now I still curse everytime I need to enable and use the php filemanager (or use hosting control panel) to edit pages... I think a 'definite comprehensive guide for permission setting' (for the wiki/documentation) would help a lot of security concerned symphonians easy there mind once and for all.

Does it only apply to config and .htaccess files? Or does this setting affect any file (even uploaded files)?

The latter - the file/directory permissions set in the installer will be applied to anything that Symphony writes:

  • .htaccess
  • manifest and contents
  • page XSL files, utilities, data sources and events (workspace/pages, etc.)
  • files uploaded via the admin interface (e.g. with file upload fields)
  • anything which extensions may write (Well, that's really up to the extension, but most should abide by this guideline.)

I don't think it's possible for PHP to write/modify a file that it doesn't have write permission for, so any browser-based file viewer would be limited by the same constraints.

Is it really such a big security problem to set the file write mode to "777"?

I can't speak with any level of authority whatsoever, so please regard the following as my (quite possibly mistaken) opinion!

Here are some ways that various user groups can be compromised:

  • FTP: An attacker obtains FTP credentials.
  • PHP: An attacker is able to upload a *.php file and execute it by pointing a browser at its URL.
  • PHP: An attacker can exploit a vulnerable eval() call.
  • PHP: An attacker is able to execute javascript on a page that an authorised user visits, and obtain their Symphony admin login, which effectively is a PHP compromise.

So long as you're using FTP securely, or better yet SFTP instead, and you know how to choose a strong password, update it occasionally, and never store it on a computer that untrusted users can access (and you also trust your hosting provider not to expose you to attacks), an attacker would probably have a hard time compromising the FTP user group.

It's not so inconceivable that an attacker could compromise the PHP user group, especially since security integrity is in the hands of the developers of Symphony, extensions, and whatever other software operates on your site.

So I think making a file writable to the FTP user group is nowhere near as risky as making it writable to the PHP user group. It's inevitable that for Symphony to work properly, some files need to be PHP-writable, but these should be kept to a minimum. Broadening permissions for other user groups is more-or-less fine, but you definitely should not broaden PHP's permissions unnecessarily.

Thank you very much, Scott. You really helped me a lot to understand these things better.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details