Tuesday, December 31, 2013
On Monday, December 30, 2013 5:26:45 PM UTC-5, Marc Munro wrote:
How can I separate the database DBA user and app access user in rails? The app user will be able to run the app but perform no DDL. The DBA user will be used for migrations.
I do not want the user that runs the rails app to be able to create, drop or modify database objects. This type of user access-rights separation is a pretty minimal best practice and I am concerned that this does not seem to be the norm in the rails world. What am I missing?
My current thinking is that I should create 2 stanzas per database in the database.yml file. One for the dba user and one for the normal app user. Does anyone have any better suggestions?
__
Marc
You need to be a little more specific re what you mean by 'database objects'.
When talking about db/migrate type activities, you are concerned with creating, modifying, and dropping tables. These actions are usually (except for sqlite) controlled by permissions associated with a database role. If the db role (username in the database.yml file) has create or alter privileges associated with it that user will be able to run migrations. That said, migrations are not typically (or should they be) run from within a rails app.
When talking about db record level activities, which correspond to ActiveRecord model CRUD actions, you are again faced with the need to modify an existing table. These changes, made in the context of a running rails app, are typically limited to table content (rather than form). The db role (username in the database.yml) must be able to modify the database tables.
You get finer grained control within the rails app by using an authorization scheme (declarative_authorization and cancan gems) together with model associations (user has profile, profile belongs to user) to control access to data.
When talking about db/migrate type activities, you are concerned with creating, modifying, and dropping tables. These actions are usually (except for sqlite) controlled by permissions associated with a database role. If the db role (username in the database.yml file) has create or alter privileges associated with it that user will be able to run migrations. That said, migrations are not typically (or should they be) run from within a rails app.
When talking about db record level activities, which correspond to ActiveRecord model CRUD actions, you are again faced with the need to modify an existing table. These changes, made in the context of a running rails app, are typically limited to table content (rather than form). The db role (username in the database.yml) must be able to modify the database tables.
You get finer grained control within the rails app by using an authorization scheme (declarative_authorization and cancan gems) together with model associations (user has profile, profile belongs to user) to control access to data.
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/cf2be7c1-d673-42a5-b3b6-34877b5eaf03%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment