dbo.master database

We have some client software developed by 3rd party that is used internally
and requires use of our SQL server. We've had some problems with this
software in the past and the developers solution was to add the dbclient
login (used by the client software) to the dbo (owner) group of the SQL
master database. This is concerns me. Is there any reason that client
software should have full access to the SQL master database? We have many
other production databases in use on this server. I'm considering
installing a separate instance of SQL 2005 (their newest version uses SQL
2005, the version we're using now uses SQL 2000) so that they can have full
ownership access of the master database without having to worry about this
affecting other existing databases. Thanks for any advice.
RyanHi,
No need to have DBO role in Master database. Just verify the sp_who
contineously for some time and confirm the
application user connects to Master database (You could also use profiler).
Once you confirmed revove the dbo role for the application user from Master
database and see what happends.
If it is production I recommend you to do during a offtime during
weekends...
Thanks
Hari
SQL Server MVP
"Ryan" <Tyveil@.newsgroups.nospam> wrote in message
news:Obzny9huGHA.5044@.TK2MSFTNGP05.phx.gbl...
> We have some client software developed by 3rd party that is used
> internally and requires use of our SQL server. We've had some problems
> with this software in the past and the developers solution was to add the
> dbclient login (used by the client software) to the dbo (owner) group of
> the SQL master database. This is concerns me. Is there any reason that
> client software should have full access to the SQL master database? We
> have many other production databases in use on this server. I'm
> considering installing a separate instance of SQL 2005 (their newest
> version uses SQL 2005, the version we're using now uses SQL 2000) so that
> they can have full ownership access of the master database without having
> to worry about this affecting other existing databases. Thanks for any
> advice.
> Ryan
>|||> This is concerns me.
That seems like an unreasonable response on the part of a DBA.
Concerned is far too mild. I think terrified would be reasonable.
This sounds like a quick fix that avoided having to actually figure
out what the real problem is. It is not something that I would allow
even on a development server, and on production any auditor (if they
knew the first thing about SQL Server) would have a field day.
Perhaps if someone does the analysis to identify the actual
requirement a more reasonable solution can be found. Otherwise I
would say that running on a separate instance is probably the only
answer.
Roy Harvey
Beacon Falls, CT
On Mon, 7 Aug 2006 07:43:38 -0500, "Ryan" <Tyveil@.newsgroups.nospam>
wrote:
>We have some client software developed by 3rd party that is used internally
>and requires use of our SQL server. We've had some problems with this
>software in the past and the developers solution was to add the dbclient
>login (used by the client software) to the dbo (owner) group of the SQL
>master database. This is concerns me. Is there any reason that client
>software should have full access to the SQL master database? We have many
>other production databases in use on this server. I'm considering
>installing a separate instance of SQL 2005 (their newest version uses SQL
>2005, the version we're using now uses SQL 2000) so that they can have full
>ownership access of the master database without having to worry about this
>affecting other existing databases. Thanks for any advice.
>Ryan
>|||Roy Harvey wrote:
>> This is concerns me.
> That seems like an unreasonable response on the part of a DBA.
> Concerned is far too mild. I think terrified would be reasonable.
> This sounds like a quick fix that avoided having to actually figure
> out what the real problem is. It is not something that I would allow
> even on a development server, and on production any auditor (if they
> knew the first thing about SQL Server) would have a field day.
> Perhaps if someone does the analysis to identify the actual
> requirement a more reasonable solution can be found. Otherwise I
> would say that running on a separate instance is probably the only
> answer.
When in doubt, make everybody an admin, right? ;-)
Tracy McKibben
MCDBA
http://www.realsqlguy.com