# User without ALTER/DROP privs for production?

**URL:** <https://www.ruby-forum.com/t/user-without-alter-drop-privs-for-production/154149>\
**Category:** Rails\
**Created:** [November 25, 2008, 10:08pm UTC](https://www.ruby-forum.com/t/user-without-alter-drop-privs-for-production/154149 "2008-11-25T22:08:03Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![bouldr-matt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/85e7bf/32.png) [@bouldr-matt](https://www.ruby-forum.com/u/bouldr-matt)\
**Post date:** [November 25, 2008, 10:08pm UTC](https://www.ruby-forum.com/t/user-without-alter-drop-privs-for-production/154149/1 "2008-11-25T22:08:03Z")

</div>

Our department has started to develop some web-applications with Rails -  
finally breaking free of the java-for-everything approach. A lot of the  
pre-existing policies for deployment procedures will, naturally, need to  
be followed when moving to rails. So, I’m trying to figure out how rails  
will fit into our current deployment model…

As it stands today, developers are separated from the people in charge  
of deployment. Developers don’t have credentials to the production  
systems/databases, and when applications get moved to production, the  
database user does not have alter/drop privileges. We’ve solved the  
connection credential problems by using JNDI database pooling (with  
jRuby). I’m not sure, however, about the permission issues for our  
production database user.

Assuming we have two database users: super\_user and runtime\_user - and  
we give super\_user the ability to add/alter/drop tables, and then run  
our migrations on prod as this user - should there be any problems with  
using runtime\_user for our database pools (without add/alter/drop privs)  
for the application as it’s running in prod?

Has anyone dealt with this? If so, has it caused any problems?

Thanks,  
M@
