Column-level privileges Support for column-level privileges will be in multiple deliveries.
This delivery add the following portions:
1. Creation of the metadata table COLUMN_PRIVILEGE. This table is created when the INITIALIZE AUTHORIZATION command is run. Existing privileges are preserved, but warnings are issued referring to existing metadata tables. An UPDATE option will be added later.
2. Granting of column-level privileges Full support is present for granting column-level privileges. Privileges can be added and updated for one or more columns on a table or view. Support for WITH GRANT OPTION is coded, though not enabled until WITH GRANT OPTION is enabled at the object level.
3. SHOWDDL The SHOWDDL command displays column-level privileges. Regardless of the order the privileges were granted, SHOWDDL displays them in column order, and within each column, in the order they appear in the bitmap (SELECT, INSERT, UPDATE, REFERENCES).
4. Revoking of column-level privileges Only partially implemented. The basic operation of revoking granted column-level privileges and grant option for is implemented. All relevant security checks are performed. GRANTED BY is not implemented. RESTRICT and CASCADE options are not supported. Hence, any dependent objects remain when column-level privileges are revoked.
In addition to column-level revoke only be partially implemented, here are other items not present in this delivery:
1. Privileges can be granted to roles and revoked from roles, but REVOKE ROLE does not consider column-level privileges when determining if an object depends on a role's granted privileges. 2. Similarly, revoke at the object level does not consider column-level privileges that may allow an object to remain after an object-level privilege is revoked. 3. CREATE VIEW does not consider column-level privileges when determining if the user has authority on the referenced tables and views. 4. Run-time DML operations do not considered column-level when determining if the user has authority to perform the query.
Miscellaneous DDL and security bug fixes Fixed a testware issue with fullstack2/TEST062 that occurred during release testing
Bug 1415196 - Alter volatile table add column cores at CmpSeabaseDDL::alterSeabaseTableAddColumn()
Added a check to not allow add or drop column for volatile tables: - sqlcomp/CmpSeabaseDDLtable.cpp
Bug 1415232 - A failed create view causes a volatile table to disappear
The code to bind a view does not correctly reset the volatile schema in use session parameter in case of an error. Subsequent calls do not check for volatile objects.
Bug 1371265 - should not allow grants to DB__ROOT or current user
Added a check at grant to prevent this
Bug 1392491 - Unavailability of privmgr metadata error is incomplete
If not all the privmgr metadata is available, then a new Compile context flag called IS_AUTHORIZATION_READY is set. This flag is adjusted when a new compiler context is started, and when authorization is enabled and disabled.
When isAuthorizationEnabled is called and authorization is incomplete, error 1234 is now returned by default.
After coding changes were added, a request to not check all privmgr metadata table at context startup was requseted - a performance concern. Fix was changed to check all tables for debug builds but check only one table for release builds. If the performance problem is fixed, then we can go back and check for all privmgr tables.
Bug 1402009 - DB__ROOT is unable to grant privilege on object in private schema
When DB__ROOT executes a grant or revoke on objects it does not own, need to change the grantor from DB__ROOT to the object owner. This matches the same behavior for other DDL operations such as CREATE.
As part of this fix, the GRANTED BY clause is now allowed for GRANT statements but it won't be complete until LP bug 1414225 is done.
Bug 1414125 - User without priv can view data in metadata tables
Fixes were in place for all metadata tables except the privmgr metadata tables. The priv information was always being set to none in setupPrivInfo (NATable) and revoking a privilege was not correctly removing privilege information from object_privileges.