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
Related
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've got an oracle 11 XE database, with 3 schemas in it, that I want to create a DDL file for to make a baseline script to use with flyway.
I've tried to export just the DDL of all 3 schemas, but the resulting sql doesn't include the creation of the users, or the creation of the tablespaces. It just starts off with sql to create tables, which will not work as the users or the tablespaces don't exist.
Is there any way to do this with sql-developer or am I using the wrong tool for the job here?
I'm thinking I may need to include all the SYSTEM objects in the DDL, but no idea how importing that into a running oracle instance will work.
Any tips or hints I'd be grateful for, I'm starting to think this plan just isn't possible. :-(
Thanks
Matt
when we generate the ddl for a schema, we grab the schema objects, not the definition of the user that owns the schema, nor the tablespaces used IN the schema
you can still get those though, just open the DBA Panel -
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
Does oracle have Audit Trail as an inbuilt functionality?
Do i need to create separate table for Audit Log purpose to capture INSERT, UPDATE and DELETE changes?
Yes, Oracle does support auditing. You won't need to create the audit tables yourself, but you will need to configure the audit settings (i.e. which tables/users/queries to audit).
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/security.htm#i16445