Re: How to trap the user's login program and disallow if Windows based?

Thanks, Jim.

A few folks have privately written to me asking how to set up the Meanie Message; I must point out, I'd never actually DO such a thing, but just that I've WANTED to, more than a few times. (I did tell them how to do it, but also clarifying that I was being sarcastic when I wrote the original note, and that I've never put such a thing in practice.)

I think DBA's and everyone else can be driven to the edge of the cliff; and I'm generally regarded as a patient, caring, good mentor/teacher type (as opposed to the 'I am a DBA, and even God needs to get me to sign His Hall Pass' type; I personally loathe such people and use every means possible to have them got rid of).

But there ARE those days and times, when every single possible awful thing happens at once; we're only human, after all, despite rumors to the contrary.

Like when VI 'breaks' and Development is SCREAMING, (isn't it bloody annoying when technical people (not end users mind you) don't bother to say anything more than like "ODBC Call Fail!") and it's one of your programmers spooling some monstrous output from SQL*PLUS into /tmp or /usr/tmp? "Ah, sailor, what were you thinking, doing that? A few of your friends would cheerfully lynch you about now, like the whole department."

Or:

P1 (production, I've never been keen on instance names like "J.R.R. Tolkien" table
cbs_feeder
(flat table, 25 million rows)

D1 (guess? development, thankfully another machine as well as instance)

Programmer wants to test program she wrote.

Solution?

CREATE TABLE test_whatever
AS
SELECT *
from cbs_feeder_at_P1;

Those are the kind of days when the Nasty Message moves to the front page in my fantasy world.

Oh, in closing:

Big mess. Nevermind what. Me, my DBA's, our best programmer, my quasi-boss are crammed into a cubicle trying to help a developer. <omitting much>

Among other things, she couldn't make the table have a decent, unique, primary key.
So she added the AMOUNT column to the list comprising the columns for the PK.

Aspirins. Leave. Eat a big steak, have drinks. Go to bed.

RSH. "Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:S0gL8.111814$ux5.169010_at_rwcrnsc51.ops.asp.att.net...
> I must say Ilike your sense of humor.
> Jim
> "RSH" <RSH_Oracle_at_worldnet.att.net> wrote in message
> news:A6fL8.24092$UT.1657805_at_bgtnsc05-news.ops.worldnet.att.net...
> > Andy, we did it in a much less elegant way than Daniel Morgan's
suggestion
> > (which sounds cool); we had the same worries and fears about people
> running
> > amuck with Access and SQL*PLUS and other tools, untrammeled by picky
> things
> > like program logic.
> >
> > But we just built a bunch of roles like:
> >
> > ST_TAX_AUDITOR
> > FED_TAX_AUDITOR
> > ANNOYING_TAX_LAWYER
> > PROP_TAX
> > PAY_TAX
> > CFO_SEE_NOT_TOUCH
> >
> > and so forth, and passworded the roles and ensured that our create user
> > scripts never gave anybody anything but CONNECT and all roles were
> assigned
> > as NOT default.
> >
> > The individual apps would do the role activation and supply the
password.
> > It's ugly, it's bugged me, but it worked. So anyone not logged in
through
> > one of our client apps (that would check out the ROLES assigned to the
> user
> > prior to granting access, and only after they CONNECTed, and then
activate
> > the needed role(s)) would get a hearty howdy-do from SQL*PLUS, presuming
> > they knew how to get that far in either UNIX or Windows:
> >
> > SQL> select sysdate from dual;
> > ORA-14492: The DBA Staff will be quite annoyed with you
> >
> > Access, SQL Windows, and Powerbuilder were less gracious in their
> reception
> > of unexpected guests.
> >
> > I had sometimes been tempted to twiddle a few things so it would look
more
> > like:
> >
> > Oracle 7.2.3 blather blather blather
> > more blather
> >
> > Welcome to SQL*PLUS!
> >
> > You aren't supposed to be using this tool, and won't be allowed to do
> > anything while here, but a prompt follows. Please type 'exit' (without
the
> > quotes) followed by depressing the ENTER key when you are thoroughly
> bored.
> > The DBA Team on X8-1234 will be more than happy to assist with any
special
> > requirements that you might have. That's what they pay us for. Systems
> > Development can be reached on X8-2212; they do the long, tedious things;
> > however, they are much more friendly.
> >
> > SQL>
> >
> > I said, I was tempted. Apologies all around to developers, DBA's, end
> users,
> > and anyone else I've left out.
> >
> > But haven't you all just wanted to do that, just once?
> >
> > RSH.
> >
> > "Andy" <enzoweb_at_hotmail.com> wrote in message
> > news:8d4033cd.0206041503.4c37138e_at_posting.google.com...
> > > Oracle RDBMS V8.0.6 on Solaris 2.7
> > >
> > > I can remember that there is a way to trap the program name a user is
> > > logging into the database with, and disallow it if it is something
> > > like TOAD or ACCESS.
> > >
> > > Here is the problem:
> > >
> > > We have an application which connects into the database with the
> > > password hard-coded and which everyone knows. This application userid
> > > is also the schema owner. The developers also use TOAD. We can change
> > > the application password but it is hard coded in plain text and
> > > everyone knows how to see it. So the Developers have a habit of
> > > signing on to TOAD as the application owner and therefore have total
> > > access to the tables.
> > >
> > > I know that I can create a trigger at logon to run some SQL, but
> > >
> > > 1. Not sure if it works on the V806 we are running.
> > > 2. Don't know how to code it.
> > >
> > > So, I want it to go -
> > >
> > > login - check program name - if user = schema.owner and program !=
> > > program.name then kill session (and maybe issue a nasty message).
> > >
> > > Does anyone have an example of this I can use?
> > >
> > > Thanks.
> >
> >

>
> Received on Thu Jun 06 2002 - 14:52:41 CDT