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.
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.
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.