I usually grant all privileges to the database user except the ability to GRANT or remove other permissions. User access is restricted by IP to prevent unauthorized access from an external client.
Capistrano itself doesn't provide any special task for changing privileges but you can extend the base deploy strategy with your own tasks if you want. You can use Capistrano callbacks to grant/remove permissions before a migration task is executed. Simone -- http://www.simonecarletti.com On Wed, Mar 11, 2009 at 7:50 PM, Ryan <[email protected]> wrote: > > Hi, > > 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. > > Ryan > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
