Hello Kieth you wrote: It would have been better to give your developer "truncate" only privileges,
You mean: grant truncate on owner.table to user. No such grant. The closest I could find is: Create procedure that truncate the table as the owner and grant execute on the procedure to the user. Any better ideas? BTW - I did not wrote that he dropped the tables using some developing tool called magic because he forgot to switch back to the regular user after the truncate. Yechiel Adar Mehish ----- Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Monday, May 06, 2002 5:53 PM > this is exactly my point. > > It would have been better to give your developer > "truncate" only privileges, and that too only on a few > tables... but NEVER the Oracle schema owner password! > NEVER. > > But, you too gave it away! you too Brutus! Even > though you are quite averse to doing so. > > Think about it, this happens everyday. Whether you > like it or not, you have MASTER, TEST, PRODUCTION, > DEVELOPMENT, STAGING... instances, and your schema > passwords are floating around, and you have no > control. And, you promise that you will never give > the schema password out ever again, but you know you > will... you will be forced to... your director will > make you... and if you fight it any win, your > developer productivity will be seriously compromised. > > You need to have a means of giving the schema access > without giving away the full house. And the solution > is NOT via a read-only user. A read-only user is > useless. You cannot do any serious work in a read > only user. Been there done that. Giving Oracle > privileges, to users, as a case-by-case request, is > IMPOSSIBLE for you to manage, UNREASONABLE and NOT > FEASIBLE. > > Anyway, NEVER give the ORACLE PASSWORD away. Only > encrypted access. And, let Dom Phoc work right in the > owner schema. There will be no problem, if you can > GUARANTEE limited access, full audits on everything > Dom does via this access, including select statements. > Dom Phoc will not be viewing the Salaries, and Credit > Card numbers now... not if its being audited. > > At the expense of sounding like a sales person, let me > point this out again for the benefit of the group: > And, you certainly need to look at it: > http://www.iraje.com/docs/ActiveSecureDesigner.htm > > I will find forward you some more info. > > Keith > > > > Date: Sun, 05 May 2002 03:48:18 -0800 > To: "Multiple recipients of list ORACLE-L" > <[EMAIL PROTECTED]> > Reply-to: [EMAIL PROTECTED] > Organization: Fat City Network Services, San Diego, > California > > > Well , just to keep things jumping. > > Last week I deviated from our rule and gave a > responsible user > that needed truncate on tables the password for the > owner of the > schema. > > Guess what? Today he comes to me to recreate 2 tables > that he dropped. > > Go figure. > > Yechiel Adar > Mehish > > ----- Original Message ----- > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > Sent: Friday, May 03, 2002 5:53 PM > > > > Yechiel, > > Yes, I have been there, done that, over and over... > > But then, there is a "Toyota Corolla" solution and > > maybe a "Ferrari Testarosa" solution. > > > > If we can control "Dom Phoc" without tieing his > hands > > behind the back, wouldn't that would be the best: > > white paper: > > http://www.iraje.com/docs/ActiveSecureDesigner.htm > > > > > > Keith > > > > > > Date: Thu, 02 May 2002 11:48:38 -0800 > > To: "Multiple recipients of list ORACLE-L" > > <[EMAIL PROTECTED]> > > Reply-to: [EMAIL PROTECTED] > > Organization: Fat City Network Services, San Diego, > > California > > > > > > > > Well Keith > > > > Our solution to the <Doom Phoc (and their siblings)> > > is: > > > > Do not grant they rights to do any DDL either in > test > > nor in prod. > > > > The dab stuff does all the DDL work. > > Sure it is an added chore, but after tracking down, > a > > few times, tables > > that > > were dropped > > inadvertently by users (their tool did it by itself) > > we now use the > > following policy: > > > > Every application has two user id's: > > Owner, with password known only to the DBA group. > > User with rights for select, insert, update, delete > > ONLY. > > > > It works. > > > > Yechiel Adar > > Mehish > > > > ----- Original Message ----- > > To: Multiple recipients of list ORACLE-L > > <[EMAIL PROTECTED]> > > Sent: Thursday, May 02, 2002 7:54 PM > > > > > > > Lisa, > > > There is only so much you can control via a model, > > > since it remains a process away from the DB, and > > > cannot be enforced via privileges, etc. So, we > are > > > always in the hands of Dom Phoc (and their > > siblings), > > > who can do "stuff" even in the production database > > > with SQLPLus/TOAD/... Under this schenario, do > you > > > sleep well at night? > > > > > > So, we said lets work with our Dom Phoc's. On > > > production databases, we will STRIP them off of > the > > > Oracle database passwords. No password, no > change. > > > ENFORCED! Now, I can sleep well at night. > > > > > > How? Not via models. Via a solution involving the > > > following, and it seems to be working for us well: > > > > ActiveDesigner/ActiveChangeManager/ActiveCompare/A+ > > > White Paper: > > > http://www.iraje.com/docs/ActiveSecureDesigner.htm > > > > > > Take charge of the "Dom Phocs" in your org! > > > > > > Keith > > > > > > > > > > > > > > > > > > > > > To: "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]>, > > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > > Date: Wed, 1 May 2002 16:06:00 -0500 > > > > > > > > > > > > > > > > > > Well, for one thing, if your developer, Dom Phoc, > > > starts changing crap > > > in > > > your database (as has happened to me in the past) > a > > > compare to the dev > > > model > > > would be great because my development changes > would > > be > > > in the model, > > > not in > > > the test or production databases. In that > specific > > > case I had to TRUST > > > him > > > (what? trust him after what he just did?) to > change > > > everything back, > > > or > > > restore from a backup, which would have been very > > time > > > consuming. > > > > > > I was one large ball of raging hormones that day > and > > I > > > took it all out > > > on > > > him. We don't work on the same projects anymore. > > > > > > Lisa Koivu > > > Oracle Database Administrator > > > Fairfield Resorts, Inc. > > > 5259 Coconut Creek Parkway > > > Ft. Lauderdale, FL, USA 33063 > > > > > > > > > > -----Original Message----- > > > > From: Keith Peterson [SMTP:[EMAIL PROTECTED]] > > > > Sent: Wednesday, May 01, 2002 5:50 PM > > > > To: Multiple recipients of list ORACLE-L > > > > Subject: RE: ERD generation tool - Active > > > Comparisons > > > > > > > > Am I speaking to the wind .... > > > > > > > > For Compares, why would you compare the MODEL > with > > > the > > > > DATABASE...like going from US to London via > > Tokyo... > > > > ... and you get to pay more, like... you pay not > > for > > > > distance, but for "time in the air"... If a tool > > > takes > > > > longer to do something, makes more mistakes, is > > > bumpy > > > > and complex... you get to pay more. > > > > > > > > For compares, someone tell me what beats > > > > ActiveCompare: > > > > http://www.iraje.com/compare-diff.htm > > > > > > > > http://www.iraje.com/ActiveCompare_viewlet.html > > > > > > > > > > > > ...and I will switch my tool. > > > > > > > > Keith > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness > http://health.yahoo.com > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Keith Peterson > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Yechiel Adar INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
