Re: ERD generation tool - Active SCM

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 <ORACLE-L_at_fatcity.com> 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"
> <ORACLE-L_at_fatcity.com>
> Reply-to: ORACLE-L_at_fatcity.com
> 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
> <ORACLE-L_at_fatcity.com>
> 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"
> > <ORACLE-L_at_fatcity.com>
> > Reply-to: ORACLE-L_at_fatcity.com
> > 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
> > <ORACLE-L_at_fatcity.com>
> > 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: "'ORACLE-L_at_fatcity.com'"
> <ORACLE-L_at_fatcity.com>,
> > > "'keithpson_at_yahoo.com'" <keithpson_at_yahoo.com>
> > > 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:keithpson_at_yahoo.com]
> > > > 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: keithpson_at_yahoo.com
>
> 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: ListGuru_at_fatcity.com (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: adaryechiel_at_hotmail.com

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: ListGuru_at_fatcity.com (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).