Just deny login if your trigger does not know the program.
Check the archives for example scripts for login triggers.
Yechiel Adar
Mehish
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 8:08 PM
Oups ! you're right.
Yechiel,
this is a never-ending chase. security by attempting to control what
program is to be used is useless. it will always be broken - or the DBA
will always be stuck monitoring what is being used.
security based on Oracle Roles is the only good answer.
Tom Mercadante
Oracle Certified
http://www.orsweb.com/downloads/source/440.html
I don't think this would prevent determined people from logging in though.
IP addresses, machine names and program names can all be spoofed.
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
Systems Admin Operations | Admin. et Exploit. des
Hi All,
We have users that have OPS$ accounts that have full DML privs when they
run forms application via citrix. Currently they do
not have sqlplus,etc. There is a requirement that some can have
sqlplus,toad,etc. I know you can set up security for sqlplus,etc
using product_user_profile but
In homemade applications, by default users have a role
with read only, in the applications we change the
default role that allows insert, update, delete.
I've not tested this scenario but how about if, in a
database logon trigger, you check the
v$process.program field then depending of that
Except for the fact that they could always change the program name that they
are running to match what you need. Then that security is bypassed.
-Original Message-
Sent: Thursday, October 03, 2002 11:08 AM
To: Multiple recipients of list ORACLE-L
In homemade applications, by
Title: RE: Restrict certain database access using 3rd party tools.
From the TOAD help file ...
Although TOAD is intended as a developer's tool, TOAD can be made read-only via the two license files that come with TOAD, READONLY.LIC and FULLTOAD.LIC.
TOAD.EXE only reads TOAD.LIC to determine
Rick,
Can you change the forms application?
If so, then a really simple way of doing this is to grant insert, update and
delete access to the tables to an Oracle role.
When the form starts, enable that role to grant access to the tables. By
default, the role would not be enabled for the user.
Oups ! you're right.
--- Kevin Lange [EMAIL PROTECTED] a écrit : Except
for the fact that they could always change
the program name that they
are running to match what you need. Then that
security is bypassed.
-Original Message-
Sent: Thursday, October 03, 2002 11:08 AM
Title: RE: Restrict certain database access using 3rd party tools.
Stupid DBA trick #32, or how to drive your DBA colleague wild on April Fool's day:
go over to her machine, and change the name of the SQL*Plus executable (%ORACLE_HOME%\bin\sqlplusw.exe, plus80w.exe or whatever
Title: RE: Restrict certain database access using 3rd party tools.
P.S. IIRC this will happen with any client program using SQL*Net:
e.g. change My_program.exe to (My_program).exe and SQL*Net will be unable to establish a connection.
-Original Message-
From: Jacques Kilchoer
access using 3rd party tools.
P.S. IIRC this will happen with any client program using SQL*Net:
e.g. change My_program.exe to (My_program).exe and SQL*Net will be
unable to establish a connection.
-Original Message-
From: Jacques Kilchoer
Stupid DBA trick #32, or how to drive
12 matches
Mail list logo
