Download
2013-04-09, 18:09:37
Hi shawn, on hosts i manage i do disable many php options, set open_basedir and define many other security measures. I guess these are part of standard setup for multisite/multiuser environment.
permission are fine, infact getsimple is able to write and modify files, only the test and warning messages are wrong. I default to sftp-username:www-data (can be root:www-data and sticky bit not set when sftp access is not needed) so i mostly user 640 and 750 or 664/775
for a full upgrade i use a scheme like this:
Then i modify gsconfig.php and upload and chmod -R g+w my themes. I still miss a wiki entry with best permissions, so i'm just trying to guess the minimal, most secure, settings. Goal is that even if (when) a malicious file gets uploaded to getsimple upload dir, it can't be executed (in my nginx setup i do my best to disallow that risk, even if the file is disguised as an image or the attacker uses other tricks to run it) and offer maximum protection to files and folders so that it would not be easy to compromise the site or, worst, the full server.
One issue with actual GS version is that tries to use php verbs (exec chmod etc) that are commonly disabled in secure setups. And are not needed at all. In fact everything works fine, but a few wrong error messages sometimes popup. I think the problem is not about setting GSCHMOD to anything special, but testing should be done on capabilities (or error messages).
After i successfully modify a file (ie, i change Local Timezone) on some setup an error popup telling gs is unable to write files and suggesting me to chmod 777 a few directories. But that files has already been successfully modified! So getsimple works fine, but the error message is wrong.
That's not a problem for me, i'm able to modify my servers to suit my needs, but maybe for GS 3.3 we could try to get a more secure setup and a build that works even on secure machine. Or at least provide complete guidelines about directory permissions, and per-site php settings needed.
Code:
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source, phpinfopermission are fine, infact getsimple is able to write and modify files, only the test and warning messages are wrong. I default to sftp-username:www-data (can be root:www-data and sticky bit not set when sftp access is not needed) so i mostly user 640 and 750 or 664/775
for a full upgrade i use a scheme like this:
Code:
; --- gs update
/bin/cp gs/admin/* /home/sftp-username/mywebsite.org/admin/ -R
/bin/cp gs/index.php /home/sftp-username/mywebsite.org/index.php
/bin/cp gs/temp.gsconfig.php /home/sftp-username/mywebsite.org/gsconfig.php
chown -R sftp-username:www-data //home/sftp-username/mywebsite.org
find //home/sftp-username/mywebsite.org -type f -exec chmod 640 {} \;
find //home/sftp-username/mywebsite.org -type d -exec chmod 750 {} \;
find //home/sftp-username/mywebsite.org -type d | xargs chmod g+s
find /home/sftp-username/mywebsite.org/data -type f -exec chmod 664 {} \;
find /home/sftp-username/mywebsite.org/data -type d -exec chmod 775 {} \;
find /home/sftp-username/mywebsite.org/backups -type f -exec chmod 664 {} \;
find /home/sftp-username/mywebsite.org/backups -type d -exec chmod 775 {} \;
/bin/rm /home/sftp-username/mywebsite.org/admin/install.php
/bin/rm /home/sftp-username/mywebsite.org/admin/setup.php
/bin/rm /home/sftp-username/mywebsite.org/admin/update.php
chmod 664 /home/sftp-username/mywebsite.org/sitemap.xmlThen i modify gsconfig.php and upload and chmod -R g+w my themes. I still miss a wiki entry with best permissions, so i'm just trying to guess the minimal, most secure, settings. Goal is that even if (when) a malicious file gets uploaded to getsimple upload dir, it can't be executed (in my nginx setup i do my best to disallow that risk, even if the file is disguised as an image or the attacker uses other tricks to run it) and offer maximum protection to files and folders so that it would not be easy to compromise the site or, worst, the full server.
One issue with actual GS version is that tries to use php verbs (exec chmod etc) that are commonly disabled in secure setups. And are not needed at all. In fact everything works fine, but a few wrong error messages sometimes popup. I think the problem is not about setting GSCHMOD to anything special, but testing should be done on capabilities (or error messages).
After i successfully modify a file (ie, i change Local Timezone) on some setup an error popup telling gs is unable to write files and suggesting me to chmod 777 a few directories. But that files has already been successfully modified! So getsimple works fine, but the error message is wrong.
That's not a problem for me, i'm able to modify my servers to suit my needs, but maybe for GS 3.3 we could try to get a more secure setup and a build that works even on secure machine. Or at least provide complete guidelines about directory permissions, and per-site php settings needed.
