Link to home
Start Free TrialLog in
Avatar of marrowyung
marrowyung

asked on

orace parameter to use

hi,

for the following Oracle command:

(.*)ALTER SYSTEM(.*)AUDIT_SYS_OPERATIONS(.*)
(.*)ALTER SYSTEM(.*)AUDIT_TRAIL(.*)
(.*)ALTER SYSTEM(.*)OS_ROLES(.*)
(.*)ALTER SYSTEM(.*)REMOTE_LISTENER(.*)
(.*)ALTER SYSTEM(.*)REMOTE_LOGIN_PASSWORDFILE(.*)
(.*)ALTER SYSTEM(.*)REMOTE_OS_AUTHENT(.*)
(.*)ALTER SYSTEM(.*)REMOTE_OS_ROLES(.*)
(.*)ALTER SYSTEM(.*)UTIL_FILE_DIR(.*)
(.*)ALTER SYSTEM(.*)SEC_CASE_SENSITIVE_LOGON(.*)
(.*)ALTER SYSTEM(.*)SEC_MAX_FAILED_LOGIN_ATTEMPTS(.*)
(.*)ALTER SYSTEM(.*)SEC_PROTOCOL_ERROR_FURTHER_ACTION(.*)
(.*)ALTER SYSTEM(.*)SEC_PROTOCOL_ERROR_TRACE_ACTION(.*)
(.*)ALTER SYSTEM(.*)SQL92_SECURITY(.*)
(.*)ALTER SYSTEM(.*)_trace_files_public(.*)
(.*)GRANT(.*)TO(.*)PUBLIC(.*)
(.*)GRANT(.*)SELECT_ANY_DICTIONARY(.*)
(.*)GRANT(.*)SELECT ANY TABLE(.*)
(.*)GRANT(.*)AUDIT SYSTEM(.*)
(.*)GRANT(.*)EXEMPT ACCESS POLICY(.*)
(.*)GRANT(.*)BECOME USER(.*)
(.*)GRANT(.*)CREATE PROCEDURE(.*)
(.*)GRANT(.*)ALTER SYSTEM(.*)
(.*)GRANT(.*)CREATE ANY LIBRARY(.*)
(.*)GRANT(.*)CREATE LIBRARY(.*)
(.*)GRANT(.*)GRANT ANY OBJECT PRIVILEGE(.*)
(.*)GRANT(.*)GRANT ANY ROLE(.*)
(.*)GRANT(.*)GRANT ANY PRIVILEGE(.*)
(.*)GRANT(.*)DELETE_CATALOG_ROLE(.*)
(.*)GRANT(.*)SELECT_CATALOG_ROLE(.*)
(.*)GRANT(.*)EXECUTE_CATALOG_ROLE(.*)
(.*)GRANT(.*)DBA(.*)
(.*)GRANT(.*)ALL ON AUD$(.*)
(.*)GRANT(.*)ALL ON USER_HISTORY$(.*)
(.*)GRANT(.*)ALL ON LINK$(.*)
(.*)GRANT(.*)ALL ON SYS.USER$(.*)
(.*)GRANT(.*)ALL ON DBA_(.*)
(.*)GRANT(.*)ALL ON SYS.SCHEDULER$_CREDENTIAL(.*)
(.*)SELECT(.*)SYS.USER$MIG(.*)


is it ok to use , any one MUST not execute and which one is normal to run , which has no risk  ?
Avatar of Alex [***Alex140181***]
Alex [***Alex140181***]
Flag of Germany image

Could you please formalize a proper question?!
Yours seems a bit weird, sorry.
Avatar of marrowyung
marrowyung

ASKER

I am sorry for it and what I means, for the above command (this is what I got), which is safe to be execute by operator ?
The most (if not all) commands above should be executed/dealt with by a DBA, not an "ordinary" operator!
What's the purpose of this all in the end?
not an "ordinary" operator!

backup can be done by operator, safe enough ,sth like this !

so the rest is too dangerous for normal operator ?
ASKER CERTIFIED SOLUTION
Avatar of Alex [***Alex140181***]
Alex [***Alex140181***]
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
how about this :

SELECT * SYS.USER$MIG

what is it do ?
what is it do ?                                  
IMHO, this doesn't matter at this point!
The question is again: What's the purpose of this all in the end?
this doesn't matter at this point!
it does matter

What's the purpose of this all in the end?

let operator know which command is dangerous and need to monitor if they are executed !
let operator know which command is dangerous and need to monitor if they are executed !                                  
In the end, virtually all commands maybe harmful if done incorrectly ;-)
Sure, a simple select will do less harm, BUT should these operators be able to see certain information?!?!

I guess, this is all more about AUDITING than "what might be dangerous..."

I suggest to be very strict with your grants and permissions, plus activate auditing all the stuff you're interested in ;-)
In the end, virtually all commands maybe harmful if done incorrectly ;-)

yeah, but backup is not !

Sure, a simple select will do less harm, BUT should these operators be able to see certain information?!?!

yeah!

we just want to detect who is running that and see if it is allowed.

plus activate auditing all the stuff you're interested in ;-)

how to audit more  ? more the audit, the slow the DB is.

or we use monitor approach and this is what we are going to monitor, what command MUST we monitor so we can see who do bad thing!

but the more to monitor the busyier is the monitor system.
We cannot define these status for you! You/your IT team has to define the commands and actions which might be "dangerous" or harmful in your aspect to your system and environment.
There is no "these commands are dangerous" in general, sorry!

And yes, the more you're going to audit, the more it has a certain impact upon the overall performance of your database (whereas this should be very little if done correctly)...

Keep in mind: even a "No" can be an/the answer, too ;-)
tks
You're welcome ;-)