Hi,
I'm wondering if anyone has noticed or could confirm if a particular hole was patched.
Here is the situation: Our dba's (I'm a dev) recently installed PSU patch 18031726.
Previous to this, one of our vendor apps had views that used some form of "SELECT [something] FROM DUAL". The views are owned by the schema-owner, and by default the App user is granted Select, Update, Insert, and Delete on all of the schema-owner's views (I'm aware that this is against best practices regarding DML on dual, but sys.dual itself does not have DML grants).
All my googling refers to the notion that all underlying objects of a view must have all permissions that will be then granted to the grantee, including sys.dual.
But again--sys.Dual *only* has SELECT granted to public, no other explict grants are given. However schema-owner granted the DML grants on these views to the 3rd party (app user) *without error*. No DML was ever actually done--but the grants were allowed without error (always logged into Toad as Schema-owner, not sys). My guess is this was an oversight in Oracle, though it's likey any attempt at DML to dual would have errored, even though the viewe had DML grants.
Now, since the patching, when these views are created and the grants are given to app-user by the schema-owner, we see the error Ora 01720 Grant option does not exist for sys.dual
SO bottom line...circumstantially I would like to attribute this new error (now correctly pointing out that Dual has no DML grants) to the security patch, but I can't close this issue in my head until I get some form of confirmation that yes--Oracle found this lack of raising an error on the grants and it was corrected in this patch.
Has anyone come across this behavior, i.e, sudden errors after a patch involving some (misguided and against best practices, admittedly) DML grants on views that include Dual?
Thanks,
Jim