One option is to set up another environment (development, test, production, migration) with a separate entry in database.yml, and a db user with increased privileges vs the production user. The capistrano migrate task takes a parameter specifying the Rails environment.
I agree that you should also do IP restriction, though that solves a different problem. The less-privileged production user makes sure a bug *in the app* doesn't do something catastrophic. There are, of course, backups, but downtime costs money. :) Sarah On Wed, Mar 11, 2009 at 11:50 AM, Ryan <rlmar...@gmail.com> wrote: > I'm pretty new to Rails and Capistrano and am in the middle or > deploying my first application. I'm wondering about the database > privileges the production user should have. It seems to me that the > db user should be locked down (only read/write to existing tables, no > creating or dropping tables, etc.) when the Rails application is > running. But when the application is being deployed, the user must > have those extended privileges to do the migration. Everywhere I > read, the database scripts create a db user will all privileges > granted - which works for the deployment, but seems too insecure for > everyday use. Am I wrong in thinking this, and should I just grant > all privileges and not worry about it? Or is there something I'm > missing in the Capistrano setup that grants the db user privileges at > the beginning, then removes them at the end? Thanks for any help. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to capistrano-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
