Skip to Main Content
  • Questions
  • Permissions to create triggers over several schemas

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question.

Asked: March 09, 2017 - 10:08 am UTC

Last updated: March 22, 2017 - 1:49 am UTC

Version: 11R2

Viewed 10K+ times! This question is

You Asked

I have a 'normal' schema S, and a schema that stores history H (it contains all tables of S, added with some audit columns, but stripped of any keys).
Whenever a DML happens on S, it has to be stored within H (If S contains a table T, and we insert a record, H will contain a table T' with all the new inserted data, with a timestamp, user and a predicate 'INSERT').
Due to the nature of the application, and for security reasons, we have following restrictions:
- S and H cannot create triggers
- No synonyms nor grants are created between S and H.
Now we need triggers to replicate the DML on S towards H, so the solution was to create the triggers within schema D, which has the role of DBA:
CREATE TRIGGER TR_T
AFTER INSERT OR UPDATE ON S.T
FOR EACH ROW
BEGIN
INSERT INTO H.T' VALUES('INSERT',user,sysdate,:new, ...);
END;
The problem is that although
SELECT * FROM S.T
and
SELECT * FROM H.T'
both give results when queried from D
the trigger itself doesn't compile (stays invalid) for the reason
ORA-00942: table or view does not exist
pointing to the H.T'
Replacing it with T' (so without the schema-prefix) doesn't work either
If I add a synonym for H.T', it works, but as I said, this isn't an option for us.

and Chris said...

Seriously?! You're creating a third user with DBA privileges because that's "better security" than granting privileges between your two users??

Creating a third schema to hold your code can improve security. But not if you grant it DBA! You're giving it way more power than it needs.

And in any case, you still need to grant this third user permissions on the tables in S and H explicitly:

grant dba to dbau identified by dbau;
grant unlimited tablespace to su identified by su;
grant unlimited tablespace to hu identified by hu;

create table su.t (
  x int 
);

create table hu.th (
  x int 
);

conn dbau/dbau

create or replace trigger trg 
before insert on su.t
for each row
begin
  insert into hu.th values (:new.x);
end;
/
sho err

LINE/COL ERROR
-------- -----------------------------------------------
2/3      PL/SQL: SQL Statement ignored
2/18     PL/SQL: ORA-00942: table or view does not exist

conn chris/chris

grant select, insert on su.t to dbau;
grant select, insert on hu.th to dbau;

conn dbau/dbau

create or replace trigger trg 
before insert on su.t
for each row
begin
  insert into hu.th values (:new.x);
end;
/
sho err

No errors.


You need direct grants on objects to use them in PL/SQL. Not via a role:

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1065832643319

Revoke DBA from your third user. Just grant it the privileges it needs!

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

non-DBA

A reader, March 09, 2017 - 11:51 am UTC

User D isn't a dba in the strict sense, it is a superuser for our application (also used for batches etc...), but we can grant this user all roles possible, but not direct access to an object outside its own schema. The main problem is (and I cannot stress enough I wasn't part of that decision) we don't use grants and synonyms outside of our third-party security system, so that's why we're stuck at this for the moment. I know I can fix it with direct grants, but my hands are tied. The question we posted was only a last resort to convince that it wasn't our team that didn't find a solution, but there just isn't a solution within the bounds we are dealing with.
Chris Saxon
March 09, 2017 - 1:19 pm UTC

OK, an application superuser makes a bit more sense :)

But the premise of "only grant via roles" is flawed. This user needs direct grants on the tables to use them in PL/SQL. As you suspect, these are necessary to create triggers in the "god" schema.

Wouldn't a SELECT/INSERT ANY TABLE on schema D fix this?

Ramon Caballero, March 21, 2017 - 12:39 pm UTC

Just wondering, wouldn't the privileges SELECT ANY TABLE, INSERT ANY TABLE and ALTER ANY TABLE on Schema D fix the error?
And if this works I wouldn't use the same schema D as the batch user, create another one for batches. Nobody and nothing should connect to the overpowered user D.
Connor McDonald
March 22, 2017 - 1:49 am UTC

"Just wondering, wouldn't the privileges SELECT ANY TABLE, INSERT ANY TABLE and ALTER ANY TABLE on Schema D fix the error? "

Yes, but anything with "ANY" in its name is something you always want to think very very carefully about before granting to anyone.

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library