7 ms·
Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?
by enz 8y ago
Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?
- jszymborski 8y agoYup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).
- hnzix 8y agoI inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline. php app/console cache:clear --env=prod --no-debug php app/console assetic:dump php app/console cache:warmup --env=prod --no-debug chown -R apache:apache . # fix owner chmod -R u=rwx,g=rwx,o=rx app/cache # fix cache perms apachectl restart # bounce Apache, otherwise it can throw segfaults
- 0x0 8y agoThat chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.
- daledavies 8y agoThis is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.
- deckiedan 8y agoHow I've been running multiple wordpress installs for years: user: $sitename - the 'owner' of the whole hosted dir. rwX user: $sitename-PHP - the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files. user: nginx - can read all files except the wp-config.php file, which is limited to only the $sitename group reading it. then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them). Works pretty well for me.
- gdfasfklshg4 8y agoThe chmod is pretty suspect as well.
- y4mi 8y agoits really not... cache is the equivalent to /tmp check permissions there sometimes.
- gdfasfklshg4 8y agoUnless it is mounted noexec why would you risk setting the exec bits on files that are writable by the webserver?
- DCoder 8y agoThe exec bit is also important for accessing sub/directories. Although for that you should use X instead of x…
- gdfasfklshg4 8y agoOf course. I actually regard this as a fairly major issue with the Linux permissions model. Far too many people do as the GP and accidentally set all the files to executable. Cleaning up after someone has done this on a nested set of subdirectories is quite tedious. NB if anyone has ever run: chmod -R u+x . or equivalent and you run chmod -R u=rwX the files will stay executable... You can always use find to set all files to +x and directories to -x but then what if some of files needed to be executable?
- gdfasfklshg4 8y agoThis is sort of a how to not do things: 1. chown -R apache:apache . # Now the webserver will have write access over the whole application! 2. chmod -R u=rwx,g=rwx,o=rx app/cache # Now all files in cache are executable and writable by the webserver! 3. apachectl restart # graceful might be better here. Securitywise 1 and 2 are not good things to do.
- mikl 8y agoGenerally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.
- msie 8y agoHmmm Symfony uses routes declared in a file...