7 ms·

I 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/con

by hnzix 8y ago

I 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 ago
That 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 ago
  This 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 ago
    How 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 ago
  The chmod is pretty suspect as well.
  - y4mi 8y ago
    its really not... cache is the equivalent to /tmp check permissions there sometimes.
    - gdfasfklshg4 8y ago
      Unless it is mounted noexec why would you risk setting the exec bits on files that are writable by the webserver?
      - DCoder 8y ago
        The exec bit is also important for accessing sub/directories. Although for that you should use X instead of x…
        gdfasfklshg4 8y ago
        Of 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 ago
This 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.

by hnzix 8y ago

0x0 8y ago

That 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 ago
This 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 ago
  How 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 ago
The chmod is pretty suspect as well.
- y4mi 8y ago
  its really not... cache is the equivalent to /tmp check permissions there sometimes.
  - gdfasfklshg4 8y ago
    Unless it is mounted noexec why would you risk setting the exec bits on files that are writable by the webserver?
    - DCoder 8y ago
      The exec bit is also important for accessing sub/directories. Although for that you should use X instead of x…
      - gdfasfklshg4 8y ago
        Of 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 ago

This 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.