Our application has its data structured across two schemas, let's call them Main and Archive. This is needed as some tables from the Main schema are archived into corresponding tables in the Archive schema.
The Main schema updates are run using a Liquibase servlet which is run by the Main user when the application first starts.
At the moment all archive updates are run as a separate DBA task. This is a bit inconvenient as we must engage a DBA for simple things like creating a new table in the archive schema and granting the right permissions to the Main user which is the absolute owner of all application data.
We are considering making Main user able to create/alter objects in the archive schema and embed this in our Liquibase scripts.
The Main user has been granted an APP_ADMIN_ROLE that make it entitled to CREATE, ALTER, COMMENT ON etc ANY TABLE so it is able to create and drop tables in the Archive schema.
However, we hit the problem that despite tha fact the Main user can create an Archive table it is not able to grant CRUD operations on that table to itself.
Is there any way to achieve this.
GRANT DBA TO MAIN is not an option.
Thanks in advance
For future references (and extracted from the comment of kfinity), the following solution answered the OPs question best:
A lazy fix: you can also grant CRUD operations for ANY TABLE. In your
case, you could either grant it to the Main user or the role. e.g.
grant select any table, update any table, delete any table, insert any table to APP_ADMIN_ROLE;
Related
I am using an oracle database. I am accessing that database through two users. They are userA and userB. I have created some tables, packages and procedures etc. in userA schema. Here after I want to continue my work using 'userB' and remove userA.
I granted permissions from userA to userB and created a table with a separate name by selecting all records. Then I saw that triggers and indexes have not been created. I want to know the best method to copy tables, packages and procedures with data from one user to another.
You can copy tables by backing up using expdp and then importing using impdp with the remap_schema/remap_tablespace options (example in this answer).
You cannot use this method for packages, procedures or triggers as the impdp documentation states that:
Restrictions
The mapping may not be 100 percent complete because there are certain schema references that Import is not capable of finding. For example, Import will not find schema references embedded within the body of definitions of types, views, procedures, and packages.
For triggers, REMAP_SCHEMA affects only the trigger owner.
To transfer these you will have to edit the source code of the triggers/pacakages/procedures/etc. and then recompile it on the new schema so that the schema references within the code are also updated.
I am trying to create a read-only user for an Oracle 11g Database that will be used by SQLAlchemy to query the database.
I was using an existing DBA user with SQLAlchemy and wasn't having any problems, but now with the new user, I am unable to reflect database tables.
Could not reflect: requested table(s) not available in Engine
Note that I can SELECT the tables, just not reflect them.
I am wondering what kind of permissions I need to give to the new user for it to able to reflect through SQLALchemy.
I tried copying all roles from the existing DBA to the new user, but still get the same error
I even tried some advanced roles that weren't used before (I plan on deleting and adding the user correctly again later.
DBACONSULTA is the new user I am creating.
GRANT DBA TO DBACONSULTA
GRANT EXECUTE ANY EVALUATION CONTEXT TO DBACONSULTA
GRANT ANALYZE ANY TO DBACONSULTA
GRANT SELECT ANY TABLE TO DBACONSULTA
GRANT EXECUTE ANY PROGRAM TO DBACONSULTA
With Python I use the following code:
engine=create_engine('oracle+cx_oracle://...')
metadata = MetaData()
metadata.reflect(engine, only=['tablename'])
Get the error:
Could not reflect: requested table(s) not available in Engine
I want to be able to reflect tables, without using the Declarative form from SQLAlchemy
Thanks in advance.
I believe I have found the answers.
Two things that are important:
the table name had to be in lowercase (didn't work using uppercase)
the schema was not defined (turn out it was working because the user I was using was the owner of the schema of the tables)
So, when i declare the schema and use lowercase for the tablename the reflection works.
I want to import schema to my new host. First I had created new user account:
CREATE USER test IDENTIFIED BY test;
What kind of privileges I need to grant to have super role?
(create schema, tables, packages, triggers...etc)
It's one privilege to grant me access to all of them?
You should grant only those privileges that are required for a newly created user to work. One by one.
CREATE SESSION is the first one; without it, user can't even connect to the database.
CREATE TABLE is most probably also required, if user TEST is going to create his own tables.
That's enough to get it started. Once it appears that user needs to create a procedure, you'll grant CREATE PROCEDURE. And so forth.
There are/were roles named CONNECT and RESOURCE which contained the "most frequent" privileges one needed, but their use is - as far as I can tell & in my opinion - discouraged.
I'm using Oracle's 10g version.
In the database, I would like to create a configuration table and fill it with data.
Then the other users can not change anything in it, and even better that it was not at all visible to other users. Is it possible to somehow hide the table?
Regards
Create a separate schema for that table. Create a package that provides an API to your configuration data (e.g. to get a value that is needed by another program).
Revoke CREATE SESSION privilege from that schema (i.e. just don't grant any privileges to the schema at all). Don't grant any privileges on the table. The only users who will be able to see the table are those with DBA privileges.
The only thing that database sessions will be able to do is execute the package, IF they have been granted EXECUTE privilege on it.
If you do not grant enough privileges to other users, they could not see your objects.
As security tightening exercise, I'm removing all system privileges from an oracle database user. Now this user ONLY has the following system privileges:
CREATE SESSION
UNLIMITED TABLESPACE
I was hoping that the user wont be able to do any DDL commands. But to my surprise, user can DROP TABLE in its own schema even though it can't create one.
Oracle documentation says prerequisite for DROP TABLE is "The table must be in your own schema or you must have the DROP ANY TABLE system privilege". Just that!!! I don't understand the security logic of Oracle but is there any way I can prevent Users from dropping their own tables?
The alternative would be creating another user to run the application and grant object access, which I'd rather like to avoid as there are potential issues.
A user will always have permissions to drop objects that they own. You can't prevent that by revoking privileges.
Since you're looking at tightening security, creating a new user and granting that user whatever privileges they need to manipulate the data is the right answer. The only people that ought to be logging in to a production database as a user that owns application objects are DBAs and then only when they are in the process of deploying changes to the schema. Everyone else should be logging in to the database as users other than the schema owner.
That being said, if the right solution is more work than you're prepared to undertake right now, a potential stopgap would be to create a DDL trigger on the database that throws an exception if a DROP is issued against an object in the specified schema. This is less secure than the proper solution. You may miss something when implementing the trigger, you or someone else may drop or disable the trigger and forget to re-enable it, etc. And it makes security reporting much more difficult because you've got a custom solution that isn't going to be obvious in the various security related data dictionary views which may create problems for auditors.