Small change to GL_SECURITY_PKG in EBS 12.1.2

After a recent upgrade to Oracle Applications 12.1.2, a client started experiencing problems with Discoverer reports. These reports were based on views in a custom schema that use APPS.GL_SECURITY_PKG.VALIDATE_ACCESS to restrict the returned data set. Despite no known changes to the reports or associated permissions, reports were terminating with the following error:

ORA-00942: table or view does not exist
ORA-06512: at "APPS.GL_SECURITY_PKG", line 1427

Line 1427 of GL_SECURITY_PKG starts a query against table owned by APPS to which the custom schema did not have access. While this section of the code had not changed between the original system and the upgraded one, one thing that had changed was the package header.

Here's the header from the original package:

SQL> select line
  2       , text
  3    from all_source
  4   where owner = 'APPS'
  5     and name = 'GL_SECURITY_PKG'
  6     and type = 'PACKAGE'
  7     and line <= 2
  8   order by line asc
  9  /

---------- --------------------------------------------------------------------------------
	 1 PACKAGE gl_security_pkg AS
	 2 /* $Header: gluoases.pls 120.10.12000000.1 2007/01/16 22:31:44 appldev ship $ */

And on the upgraded system:

---------- --------------------------------------------------------------------------------
	 2 /* $Header: gluoases.pls 120.10.12000000.1 2007/01/16 22:31:44 appldev ship $ */

Somehow, the GL_SECURITY_PKG was recompiled with invoker's rights (CURRENT_USER) instead of the default DEFINER rights. This explains why the custom schema was suddenly unable to access the APPS-owned tables without explicit permission to read the tables.

It may be that someone manually compiled this package with AUTHID CURRENT_USER, but it seems more likely that this was done during patching. The short-term "band-aid" fix here is to grant read permission to the custom schema on the tables referenced in APPS.GL_SECURITY_PKG. The longer-term solution, currently underway, is to engage with Oracle Support to determine how or why this package was recompiled with the AUTHID CURRENT_USER property, and learn if there is new guidance regarding the use of this package.

One Comment

  1. Jose Arostegui
    Posted 2 January 2013 at 15:21 | Permalink


    Adadmin is the responsible of that. I can explain it with more details if you'd need it.

    Happy new year,

Post a Comment

Your email is never published nor shared. Required fields are marked *