Re: Client application connects as schema owner - opinions please

If you had not apprised the third party developer of your requirements before they began development then you can hardly claim their coding to be defective. This is in fact a new requirement (to them) and it will cost extra to have it done the way you want. You of course should not give up your security scheme but you must be prepared to pay for it (or answer to management as to why the third party developer was not given the whole story).

My $.02
Barry

"Paul Brewer" <paul_at_paul.brewers.org.uk> wrote in message news:3cc5aa01_1_at_mk-nntp-1.news.uk.worldonline.com...
> Oracle 8.1.7EE on hp11
> (not that I think it's relevant in this case, but it's a good habit to
quote
> version).
>
> I'd appreciate your thoughts: We are a DBA team in in a large project,
> multi-team environment.
>
> We have been supplied with a bespoke application developed by a software
> house, which we are expecting to put into production in about 6 months
from
> now.
>
> One of the client-side executables is a 'Sys Admin' module, which we am
> told, 'must' connect as the schema owner (username and password are, we're
> told, hard coded in the app - this is, we feel, sub-optimal, to say the
> least).
>
> Until now, our general practice (we run many Oracle databases) has been to
> create an 'app-owner' user, and a number of 'app-user' type roles. We do
> *not* disclose the app-owner passwords to anyone outside the DBA group,
> either for development or production dbs.
>
> Even leaving aside production for the moment, in the development
environment
> one reason for this is that if anyone can drop or alter tables, our
version
> control goes down the drain. If we (the DBA team) are responsible (which
we
> are) for ensuring that changes to multiple incarnations of the database
> (development, system test, integration test, acceptance test and so forth)
> are implemented correctly and consistently at different times, then it is
> imperitive that we can control these changes as they are made. It seems to
> us that if we surrender control of the 'app-owner' password, we will in
the
> long run be doing a disservice to our developers, as anarchy will
doubtless
> result.
>
> On these (and numerous other) grounds, our inclination is to *insist* that
> the offending module be changed to connect as a 'sysadmin' user, which we
> will happily create, with whatever privileges are necessary to execute the
> app successfully (but of course no more).
>
> In the (expected) event that the third-party developers say they can't do
> this.. it'll cost more.. it's a new requirement.. we're inclined to say
that
> this comes within the scope of being defective.
>
> Are we being sane, or unreasonable?
>
> I'd welcome any (constructive) comments or criticism on this.
>
> Thanks in advance.
>
> Paul
> P.S. This is not college homework, it's a real world dilemma.
>
>
>
Received on Wed May 08 2002 - 09:44:04 CDT