Granting privileges to the PUBLIC ID

You can grant to the PUBLIC ID privileges or authorities other than CREATE_SECURE_OBJECT, system DBADM, DATAACCESS, or ACCESSCTRL.

About this task

When you grant privileges to PUBLIC, the privileges become available to all IDs at the local Db2 site, including the owner IDs of packages that are bound from a remote location. Public access is generally not a good practice when it comes to the protection of sensitive business data and critical system resources. Many compliance requirements prohibit public access to any system components. For example, the Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures restrict the use of PUBLIC.

When you grant any privilege to PUBLIC, Db2 catalog tables record the grantee of the privilege as PUBLIC. Db2 also grants the following implicit table privileges to PUBLIC for declared temporary tables:

  • All table privileges on the tables and the authority to drop the tables
  • The CREATETAB privilege to define temporary tables in the work file database
  • The USE privilege to use the table spaces in the work file database

You do not need any additional privileges to access the work file database and the temporary tables that are in it. You cannot grant or revoke table privileges for temporary tables. The Db2 catalog does not record these implicit privileges for declared temporary tables.

Because PUBLIC is a special identifier that is used by Db2 internally, you should not use PUBLIC as a primary ID or secondary ID. When a privilege is revoked from PUBLIC, authorization IDs to which the privilege was specifically granted retain the privilege.

However, when an ID uses PUBLIC privileges to perform actions, the actions and the resulting objects depend on the privileges that are currently in effect for PUBLIC. If PUBLIC loses a privilege, objects that are created with that privilege can be dropped or invalidated. The following examples demonstrate how certain objects depend on PUBLIC not losing its privileges.

Example

Suppose that Juan has the ID USER1 and that Meg has the ID USER2. Juan creates a table TAB1 and grants ALL PRIVILEGES on it to PUBLIC. Juan does not explicitly grant any privileges on the table to Meg's ID, USER2. Using the PUBLIC privileges, Meg creates a view on TAB1. Because the ID USER2 requires the SELECT privilege on TAB1 to create the view, the view is dropped if PUBLIC loses the privilege.