We are running into tablespace issues as a result of a large SYS.AUD$ table. Upon further investigation, we identified that 99% of the items in this table were SELECT actions
SELECT COUNT(*) from SYS.AUD$ where ACTION# = 3;
334698880
SELECT COUNT(*) FROM SYS.AUD$;
335176012
However, we cannot find WHY these are being logged.
No system-wide auditing privileges set for SELECT (DBA_PRIV_AUDIT_OPTS)
No system-wide statement options set for SELECT (DBA_STMT_AUDIT_OPTS)
No specific objects being tracked (DBA_OBJ_AUDIT_OPTS)
Somehow these settings are being overridden. Any suggestions with regards to places to look?
We have resolved the issue - the log-stamps allowed us to correlate the issue with a scheduled job:
Privilege auditing audits statements that use a system privilege - SQL statements that require the audited privilege to succeed are recorded
The auditing privilege EXEMPT ACCESS POLICY was enabled system wide
The EXEMPT ACCESS POLICY privilege allows a role to execute a SQL command without invoking any policy function that may be associated with the target database object
A scheduled job was executing a package that built database objects - this privilege was required to execute the package
The Auditing Section of the Oracle 11g Security Guide was extremely useful in this investigation
Oracle 11g Security Guide
Related
I'm new to Oracle and would like to know the way how to get more statistics in the case i'll describe below. I'm using SQL Developer.
First, I execute this:
SET autotrace on;
SELECT NAME
FROM PASSENGER
WHERE ID_PSG IN (
SELECT ID_PSG
FROM PASS_IN_TRIP PIT JOIN TRIP T on T.TRIP_NO = PIT.TRIP_NO
WHERE UPPER(TOWN_FROM) = 'MOSCOW'
)
In Script Output I can see info about the query from PLAN_TABLE table and after that there's the text:
Unable to gather statistics please ensure user has correct access. The
statistic feature requires that the user is granted select on
v_$sesstat, v_$statname and v_$session.
I've tried to find a solution here already, there's a link:
SQL Developer : Unable to gather system statistics : insufficient privileges
So I executed the same commands and the grants were all succeded:
GRANT CREATE session TO PRACTICE;
GRANT GATHER_SYSTEM_STATISTICS TO PRACTICE;
GRANT CONNECT TO PRACTICE;
Then I disconnected, closed SQL dev, opened it, connected again as it was described in the solution from the link, ran
execute dbms_stats.gather_system_stats ('START');
and got this:
PL/SQL procedure successfully completed.
Then I thought everything is fine and tried to execute the code from the very beginning and its Script Output was still the same as before.
Do I have to grant anything else or this statistics can be found in the other place or I just did everything wrong?
That error is about sqlplus autotrace, it's not about gathering system statistics like your linked post seems to be about.
There is a role created specifically for these grants called plustrace https://docs.oracle.com/database/121/SQPUG/ch_eight.htm#SQPUG535
To use this feature, you must create a PLAN_TABLE table in your schema
and then have the PLUSTRACE role granted to you. DBA privileges are
required to grant the PLUSTRACE role. For information on how to grant
a role and how to create the PLAN_TABLE table, see the Oracle Database
SQL Language Reference.
I am trying to investigate some database users that used to exist in the system. I am interested when and who deleted the database user from the oracle database. Does oracle have any table or way to track deleted users?
You can check the DBA_AUDIT_TRAIL or UNIFIED_AUDIT_TRAIL views for records, but if you didn't already have it enabled the audit trail won't have captured what happened and there's no way to find out.
Going forward, if you need to enable it here's a couple of posts on auditing and basic configurations. The first, from my blog, has a quick script for basic audits including account creation and deletion using Unified Auditing:
https://pmdba.wordpress.com/2020/03/10/auditing-by-the-numbers/
https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/introduction-to-auditing.html#GUID-94381464-53A3-421B-8F13-BD171C867405
https://oracle-base.com/articles/8i/auditing
The first thing to do is enable full Unified Auditing. This introduces several built-in access controls and tools that will make auditing of the database simpler. To enable Unified Auditing, complete the following steps:
Confirm whether or not UA is already enabled. If the response to the
following query is "TRUE", then it is.
SELECT * FROM V$OPTION WHERE
PARAMETER = 'Unified Auditing';
If UA is not enabled, then follow the steps in Section
4.6.13.2 of the Oracle Database Upgrade Guide to turn it on.
Enable basic audit policies:
-- audit granting and revocation of any privilege:
create audit policy stig_grant_privilege_actions actions grant, revoke;
-- audit all OLS administrative actions:
create audit policy stig_ols_admin_actions actions component = OLS all;
-- audit all user logon and logoff attempts:
create audit policy stig_user_logon_actions actions logon, logoff;
-- audit execution of any PL/SQL program unit:
create audit policy stig_execute_plsql_actions actions execute;
-- audit all user administration actions:
create audit policy stig_user_admin_actions actions create user, alter user, drop user, change password;
-- audit any database parameter changes, dynamic or static:
create audit policy stig_db_param_actions actions alter database, alter system, create spfile;
-- apply policies:
audit policy stig_grant_privilege_actions;
audit policy stig_ols_admin_actions;
audit policy stig_user_logon_actions;
audit policy stig_execute_plsql_actions;
audit policy stig_user_admin_actions;
audit policy stig_db_param_actions;
I granted the CREATE SESSION privilege to a recently created database user, and I granted him the SELECT privilege on some objects for different database schemas.
I find an apps schema (SCHEMA#) in v$session that is different from the database USERNAME recently created, and I would like to understand the phenomenon.
I think that he executes alter session set current schema and I would like to know if is it possible to revoke alter session privilege in Oracle 11g.
The documentation for the alter session statement says:
To enable and disable the SQL trace facility, you must have ALTER SESSION system privilege.
To enable or disable resumable space allocation, you must have the RESUMABLE system privilege.
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
As you don't need any privileges to perform alter session set current_schema, there is nothing you can revoke to prevent that being done. If you had actually granted alter session - which you haven't, from what you said - then you could of course still revoke that, but it would make no difference to the ability to change the current schema.
But this isn't really a problem, and is mentioned in the security guide as a good thing:
For example, a given schema might own the schema objects for a specific application. If application users have the privileges to do so, then they can connect to the database using typical database user names and use the application and the corresponding objects. However, no user can connect to the database using the schema set up for the application. This configuration prevents access to the associated objects through the schema, and provides another layer of protection for schema objects. In this case, the application could issue an ALTER SESSION SET CURRENT_SCHEMA statement to connect the user to the correct application schema.
Your recently-created user does not have any additional privileges or abilities simply by changing their current schema. They have not 'become' that schema; they can still only do the things you specified by granting select privileges on objects. They can't see anything else, and can't do any more to the objects they can see. They haven't inherited any of the privileges that schema has - so they can't create or drop objects under that schema, for instance. (You would have to explicitly grant them additional any privileges, which presumably you have no intention of doing.)
What they can do is reference those objects without having to prefix them with the schema name, and without having to create synonyms. But they can still only select from them (if that is the only privilege you granted).
I am using javers-persistence-sql version 3.7.9
I launched the sql script for table creation manually
I need to disable the ddl auto create because the schema that the application uses does not have grants for DDL.
This issue is waiting for a contributor since May 2017
https://github.com/javers/javers/issues/542
Consider contributing a PR
I use following sql to create my trigger
CREATE OR REPLACE TRIGGER INSERT_LOG
AFTER INSERT
ON EXTERNAL_SCHEME.PAYMENT
FOR EACH ROW
BEGIN
INSERT INTO MY_SCHEMA.DM_LOGGER(ID, TECHNOLOGY, WORKFLOW, NAME_EVENT, TIME_EVENT)
VALUES (PAYMENT.id, 'Repository', 'UP', (select repo.name from
pay_repository repo join pay_pmt pay on repo.id = pay_pmt.repository_id
where repo.id = pay.repository_id),(select to_char(SYSDATE, 'hh24:mi:ss') from dual));
END;
When I execute this trigger I get following exception:
01031. 00000 - "insufficient privileges"
*Cause: An attempt was made to change the current username or password
without the appropriate privilege. This error also occurs if
attempting to install a database without the necessary operating
system privileges.
When Trusted Oracle is configure in DBMS MAC, this error may occur
if the user was granted the necessary privilege at a higher label
than the current login.
*Action: Ask the database administrator to perform the operation or grant
the required privileges.
For Trusted Oracle users getting this error although granted the
the appropriate privilege at a higher label, ask the database
administrator to regrant the privilege at the appropriate label
I don't get it. I have connection to both schemes and I never want to change something. What is wrong?
the privileges seems to be missing,please execute,
grant create trigger to schemaname;
if it still gives the error then the select privileges might be missing on the tables of other schemas, for that you can run this,
grant select on otherschema.table_name to <schema_name> ;