On 6/15/11 9:39 PM, ryan weaver wrote:
I do think there is a difference between symfony1 and Symfony2 since chmod 777 in Symfony2 is not sufficient (because the new files created aren't 777, so you eventually hit a permission issue). So, chmod 777 used to be enough, but not anymore sadly.
Both symfony1 and Symfony2 use chmod 0777. The difference is that Symfony2 does not change the default umask (which defaults to 0022).
Jeremiah, you're right about having everything run as the same user. That's definitely a good way to go, but it's also just another option (and how you do it will depend on your system). I've always wanted some simple server like you described for when users are just starting or playing around - there had been some work on that at some point. So, if there's no better solution, and the solutions we have posted work, then I guess we're fine. I just want to be sure that we're recommending the best options.
The easiest solution that works for most people (nobody uses a threaded webserver with PHP, right) is to add umask(0000) to your front controller. Of course, it's also the less secure option.
Fabien
Thanks! Ryan Weaver US Office Head & Trainer - KnpLabs - Nashville, TN http://www.knplabs.com <http://www.knplabs.com/en> http://www.thatsquality.com Twitter: @weaverryan On Wed, Jun 15, 2011 at 1:59 PM, Tom Boutell <t...@punkave.com <mailto:t...@punkave.com>> wrote: As you are probably aware this is not a new problem in Symfony2 at all. Symfony1 already needed to make cache files and update log files that might involve permissions problems. (And, come to think of it, cloud problems. The cache files are necessary even in production and you can't move the ones for the core stuff to another backend other than files, right?) But you're right, it's messy and has always been messy. I submitted a patch back in the 1.0 days to make the 666/777 business configurable. (It wasn't a great patch.) Our deployment recommendations have always been to create a single user for both Apache and the command line tasks run on behalf of the website. It amazes me how many admins fight this tooth and nail, seemingly unaware that they have already configured PHP so that it is allowed to call system() anyway! Other solutions generally involve things getting screwed up eventually. You might be using a library like Zend Lucene that doesn't ensure that the directories and folders it creates all share the permissions and group ownership of the parent, etc. Command line tasks never go away, even in production - cron jobs are essential for many purposes. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com <mailto:symfony-devs@googlegroups.com> To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com <mailto:symfony-devs%2bunsubscr...@googlegroups.com> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
