-
Developers using DBA_ROLE
I've created a development environment for a development team. I've created them a user account for the shema with (what I feel is) the requisite db privileges to develop (CREATE, ALTER, DROP etc. all necessary objects).
The Team Leader has now asked for it to be given full DBA privs.
I don't think this is appropriate. The schema is their responsibility, the database is mine (and believe me when something goes wrong it will be MY RESPONSIBILITY!). They don't have any on-board DBA skills in the team - they just ring me when they can't do a particular thing, like 'create us a database'!
I did read - somewhere - a cracking explanation of why it is dangerous to give developers (particularly ones who are not very database savvy) DBA privileges. I'd like to cherry pick some pertinent points from it to use in a response.
Anyone point me towards any good docs or articles on this subject?
-
or failing that - what are your own views on the subject? What do you consider to be 'good practice'. Is there a recommended set of system privs that a ROLE like this should have?
Last edited by JMac; 10-07-2005 at 10:26 AM.
-
Try the Administrator's guide?
"The DBA Role
A predefined role, named DBA, is automatically created with every Oracle database. This role contains most database system privileges. Therefore, it is very powerful and should be granted only to fully functional database administrators."
http://download-west.oracle.com/docs.../dba.htm#14029
-
Originally Posted by JMac
The Team Leader has now asked for it to be given full DBA privs.
You need to replace the team lead.
Tamil
-
Just lie that they have the full DBA privs, I'll bet you 100 bucks they'll not notice a thing!
Tarry Singh
I'm a JOLE(JavaOracleLinuxEnthusiast)
--- Everything was meant to be---
-
I was thinking about that.
-
Hi.
Alot of the time people want visibility, rather than actually being able to do anything. I often allow access to the data dictionary and dynamic performance views to everybody:
GRANT SELECT_CATALOG_ROLE TO PUBLIC;
Alot of the time this is what they want.
If you grant people the DBA role you might as well give them the SYS password. Simple as that.
Code:
SQL> create user tim identified by tim;
User created.
SQL> grant dba to tim;
Grant succeeded.
SQL> conn tim/tim
Connected.
SQL> alter user sys identified by password;
User altered.
SQL> conn sys/password as sysdba
Connected.
SQL>
If the DBA role was for developers it would be called DEVELOPER
Cheers
Tim...
PS. If he asks again tell him Tim said no
-
Tim - he must be obeyed!
They cry out that its only a dev server so what's the problem? Indeed, if they crash it it would be their problem I'm certainly not taking any flak there. But they're a lazy bunch and see our production systems as a source of test data to help them develop. So ... DBA gives them create DBLINK privs. Once they realised this I see several links from the Dev DBs to live systems. These are validated - supposedly SECURE!!! - systems and there are the developers throwing queries at it and its all okay "because its only a READ only link".
I'm not prepared to be responsible for securing our prod systems if I can't keep them secure. If this means keeping developers away from the DBA role (even on their dev box) then so be it.
Just out of interest what other damage could they do over a DB link (the account they connect to has SELECT only privs on all the schema tables)?
-
They should never get ad hoc access to the prod system, it would be all too easy to run a humdinger of a query that has an impact on perfromance (even if its read only).
DBA privs on development is also a bad idea (IMO) as development should be as close to live as possible so they can....errrrr.....develop against it. No point in them spending weeks writing code only to find it doesn't work in live (or UAT) because of something in dev is different to live.
-
READ only privs on a production system also give them SELECT FOR UPDATE, no? Despite not being able to actually perform the update they can still lock a table and grind a production system to a halt.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|