One of our clients has requested that we include the 'db_owner' role on the database login that their website uses, so that they can upload a script (an ASP page) to run some database changes. Normally the logins for the databases hosted on our server only include 'db_reader' and 'db_writer'. Is this ok, or should I request that they forward us the sql script to run on their behalf?
Or am I being too protective? Thanks
I would suggest that you act as a filter between them and anything they might want to do to the database such as uploading and running those scripts. If they get db_owner and hose it all up, it will still probably be your head on the chopping block for letting them have it to begin with.
What kind of scripts are they running?
Rather then providing them direct access you could provide some kind of interface as TheTXI suggested. I would be very concerned about giving db_owner access unnecessarily.
That might be you, or a team member, or depending on the type of scripts you may be able to provide them some kind of web interface (thus allowing you to at least wrap some validation around the script).
But if they directly run something on the system that you don't want to it will most likely be on you (whether that be just managing a restore or something more serious)
You can get more granualar with your permissions to let them only do what you want. It would depend on how often they want to make changes and how responsible you are for their data. I would not want to grant dbo to someone unless there was a really good reason.
Make sure that they are the owner of the database not just in the dbo role. If dbchaining is on in another database with the same owner they could turn it on in their database and have dbo permissions in that other database.
Or, make them sign an agreement that says "Any damage you cause to the data or the database schema caused by you or anyone logged in under said db account is not of your fault and no blame can be put on you, etc etc" At least if they balls something up, that way you're covered and the client stays happy. Though you might want to give them a separate login for this, so that they can't blame incorrect changes on the website code.
I think that I would want to have a service level agreement that is acceptable to everyone before I would give out that much control over the database. For example, you could specify that if the client damages their databases in a way that they can't fix, your response would be limited to restoring it to a backup point of their choosing within a certain timeframe. You might also require them to maintain a specific technical contact for database issues who will be the first contact for their developers, etc. The SLA should spell out the various risks, including loss of data, inherit in having this level of capability.
In general, I'm in favor of giving more control, rather than less, if the client is willing to accept the responsibility. As a person who uses such services, I know that it can definitely improve productivity if I'm allowed to make the changes that need to be made without having to jump through hoops. I'm also willing to accept the risks involved, but I clearly know what the implications are.