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