Clone Tools
Constraints: committers
Constraints: files
Constraints: dates
TRAFODION - 3218 User still has privilege after user's role has been revoked ...

Partial support for column level privileges with QI support for:

column select

column insert

column references

column update

Also, as part of this, updated privilege code in a couple of areas:

Changed object caching code in NATable and NARoutine to store all privileges

assigned to the object when the object is cached (privDescs_). During the load

operation, the code creates bitmaps (privInfo_) for the current user. Privilege

checks are performed against the user bitmaps (privInfo_). This is in

anticipation for some performance updates when connecting to Trafodion (mxosrvr)

with different users.

Change getRoleList to include the roleID and the granteeID that granted the

privilege. The grantee can be a user or a role.

When a privilege is revoked from a role, send QI keys for every user that has

been granted to role.

  1. … 40 more files in changeset.
TRAFODION-3194 update

Fixed issue where revoke all on object did not actually revoke the privilege.

Also fixed an issue where setting up default privileges did not set the

correct default bits for object type.

  1. … 2 more files in changeset.
Fixes for TRAFODION-3194 && TRAFODION-3195

TRAFODION-3194 Revoke grant option on objects revokes more that grant option

changed Privilege Manager to set bitmaps correctly

removed unused methods from PrivMgrDesc

TRAFODION-3195: Fixes for get commands:

get schemas for user <user>:

returns schemas owned by the specified user

if current user does not have elevated privilege,

returns error if current user does not match <user>.

get schemas for role <role>:

returns schemas owned by the role,

if current user does not have elevated privilege,

returns error if current user has not been granted <role>

get [tables | views | indexes | libraries ] for user <user>:

get [functions | table_mapping_functions | procedures] for user <user>:

get [privileges | roles] for user <user>:

returns objects where <user> has at least one privilege

if current user does not have eleveted privilege

returns error if current user does not match <user>.

get [tables | views | indexes | libraries ] for role <role>:

get [functions | table_mapping_functions | procedures] for role <role>:

get [privileges | users] for <role>:

returns objects where <role> has at least one privilege

if current user does not have eleveted privilege

returns error if current user has not been granted <role>

  1. … 17 more files in changeset.
[TRAFODION-2542] Grantor is not correct when granting privileges for a role

When granting privileges and the authorization ID is not the current user but

one of roles granted to the current user, then the "granted by" clause is

required. In addition, the grantor of the privileges becomes the role specified

in the grant statement instead of the current user.

Added a CQD ALLOW_WGO_FOR_ROLES that will return an error if the user tries to

grant a privilege as a role.

Added error message (1194) when a component operation is not defined.

Added a check to not allow the WITH GRANT OPTION when granting privileges

to public

  1. … 19 more files in changeset.
TRAFODION-2538 Revoking privileges from role not invoking query invalidation

Fixed a issue where query invalidation keys were not being sent correctly when

a privilege was revoked from a role.

When a table is cached, a list of all the query invalidation keys for the user

are stored. Later, when a query is run, the compiler picks the relevant keys

and places them in the plan. When a revoke occurs, a key is sent to RMS and

the executor processes check for keys at the next execution. If the key affects

any caches, the cache entries are refreshed and plans recompiled.

Incorrect keys were being created when privileges were revoked from roles, so

queries continued to work even though the user had no more privileges.

  1. … 10 more files in changeset.
TRAFODION-2441 user has only select privilege on a table can do ... TRAFODION-2409 support privilege control(column privileges) for hive tables TRAFODION-2423 any user can perform 'initialize trafodion, drop' TRAFODION-2435 Any user can perform TRUNCATE on native Hive tables. TRAFODION-2463 Hive: Any user can do update statistics for hive tables

Fixed issues found while testing privileges with native Hive.


changed code that initializes owner privileges for views.


returning error message 1328 during attempt to grant unsupported column level

privilege on hive table.


added privilege checks for all initialize commands, error 1017 is returned if

not DB__ROOT


Returning error 1051 if TRUNCATE is attempted on a hive table where the

current user has no privilege


Privilege checks added for Hive table during update statistics

  1. … 25 more files in changeset.
[TRAFODION-2167]: Invalid query invalidation keys not working properly

When a user is revoked from a role, invalidation keys are not being

processed correctly. Therefore, users can still run queries even though

privileges have been removed. Query invalidation is complicated when

table descriptors are stored in metadata.


--> The list of priv_descs created (and stored) was changed to include an entry

for each user and each role accumulated across all grantors. (Today, each

priv_desc entry includes the users' direct grants plus grants on their

active roles.)

--> When an object is loaded into NATable or NARoutine cache, the priv_desc is

accessed and the privilege bitmap is now generated by combining the users'

privileges with privileges of their active roles. Correct invalidation keys

are now being created and stored with the object. In the first code drop,

the users' active roles are read from the role_usage table. In the next

code drop, the active roles will be stored and maintained in executor


--> When a plan is compiled, the correct invalidation keys for users, roles,

and the public authorization are added to the plan.

--> Changes in the compiler were required to handle the invalidation keys for

revoke role and revoke privilege from "PUBLIC".

--> Cleaned up the code that manages invalidation keys in privilege manager.

--> Included the correct create and redef times (if available) in the stored

object descriptor - today they are always set to 0.

--> Added new regression test to test all the revoke options.

  1. … 13 more files in changeset.
TRAFODION-2203 - a user can grant privileges that he doesn’t have ...

... to other users/roles successfully

In this case, the user/role did not get the privilege requested even though the

operation successfully completed. So the requester is lead to believe that the

privilege was granted.

ANSI states that: "warning <privilege not granted>" should be displayed for

each combination of grantee<=>privilege that was not granted. However,

privileges that can be successfully granted should be granted. The grant code

does not grant any privileges it cannot grant but is not reporting warnings if

the privilege is not granted. Ditto for revoke.

The code now reports warnings if not all privileges were granted or revoked for

both object and column privileges.

Also As part of this fix, the next piece of unifying object and column

privileges has been performed. This task:

- Replaced ColPrivEntry with a PrivMgrCoreDesc - now object and column privs

have the same base structure.

- Create a new method that performs common functions between grant and revoke


- Removed methods not longer needed

- Use column level privileges in the privsToGrant and privsToRevoke structs

- Fixed bug in showddl where privileges were not always displayed.

- Minor changes to make object and columns names more unified

  1. … 7 more files in changeset.
TRAFODION [2137] Improve metadata access time during query compilation

A change was made to return privilege information in the descriptor structure

instead of getting it when the NATable or NARoutine object is instantiated.

For tables, storing privileges in the descriptor structure allows privileges

to be saved with other table attributes in the metadata. This improves metadata

access time during initial query compilations.


--> At create time or when the object's DDL changes (redeftime), the compiler

gets the list of privs for all users. If stored descriptors is enabled,

this list is stored as part of the object definition in the TEXT table.

--> PrivMgr returns a list of bitmaps for all users granted any priv

--> the list of privs is transformed into a VirtTable

--> the VirtTable is transformed into TrafDesc

--> a packed form of the TrafDesc is stored in the TEXT table

--> When an NATable or NARoutine is instantiated, the current user's credentials

are extracted from the TrafDesc and stored in the class thereby eliminating

the need to perform I/O to get privs for the user.

  1. … 22 more files in changeset.
Merge branch 'master' into trafodion-1788







  1. … 20 more files in changeset.
[TRAFODION-1882]: Column Privilege: a user can grant column privilege to ... [TRAFODION-1788]: Grant and Revoke on table columns with referencing views ...

The main issue is that the view-col <=> referenced-col usages were not available

from the metadata.

-- create view was changed to add view-col <=> referenced-col usages to the

TEXT table. This allows NATable and privilege management to retrieve this

information. No upgrade is required

-- Privilege management was changed to see if views could still exist based

only on column level privileges.

-- Grants and revokes on referenced columns for objects are now propagated to

to referencing views

-- Fixed an issue during column grants where column ordinals were not checked

correctly [TRAFODION-1882]

-- Fixed an issue where DB__ROOT, acting as schema owner, was able to grant

privileges that the schema owner was not able to grant,

  1. … 15 more files in changeset.
TRAFODION-1856: Revoke - object and column privilege checks not integrated for constraints

Today, when revoking the object REFERENCES privilege, the revoke fails if there

are any RI constraints that require the privilege. However, there may be column

level privileges that exist that would still allow the constraint to be present.

Conversely, when revoking column REFERENCES privilege, the revoke does not

check to see if REFERENCES privilege has been granted at the object level.

In fact, the revoke operation does not check for dependencies on constraints


For example:


create table dept( dept_no int not null primary key, dept_name char(50));

grant references on table dept to user2;

grant references(dept_no) to user2;


create table empl(empl_no int not null primary key, dept_no int not null);

alter table empl add constraint empl_dept

foreign key (dept_no) references dept;

user1 should be able to "revoke references on table dept from user2" because

user2 still has the references privileges on column dept_no. Vice versa, user1

should be able to "revoke references(dept_no) on dept from user2" because user2

still has the references privilege on table dept.

To make this work, several changes were implemented:

In the existing code, object level privileges use one set of structures to

manage privileges (PrivMgrCoreDesc) and column level privileges use another

(ColPrivEntry). The ColPrivEntry class was changed to use the same base

"PrivMgrCoreDesc" structure as object privileges. This makes comparing things

between objects and columns easier. There is still more work to do in this


There is a method called dealWithConstraints that, among other things, checks

to see if the revoke can occur. Changes were made to check for column level

privileges if object level privileges were no longer available. Revoking

column level privilege now calls this method to make sure the revoke can


The dealWithConstraints change required updates to the query that retrieved

referenced table information. In addition to returning the referencing table,

the list of referenced table columns associated with each constraint was

needed. The column information returned was transformed into a new

ColumnReference structure attached to the existing ObjectUsage and

ObjectReference classes. Changes were also required in getConstraintName to get

the RI constraint related to the column which no longer has the privilege.

In addition, the code to remove column level privileges when object level

privileges was removed. In SQL, each grant needs a separate revoke to remove.

So this code did not follow ANSI standard.

  1. … 9 more files in changeset.
Privilege fixes for TRAFODION-12, TRAFODION-1761, and TRAFODION-1773

TRAFODION-12 Grant Revoke Enhancements

-- Revoke: added code to verify that when column privileges are revoked then

the remaining grants are is still intact. It does this by starting at the

beginning of the privilege tree and rebuilding it from top to bottom with

the requested privilege changes. If the revoke causes part of the tree to

be unaccessible (a broken branch), the revoke operation fails.

TRAFODION-1761 Grant and Revoke on table with referencing views does not work

-- When granting INSERT, UPDATE, or DELETE object privilege(s) on a table that

is referenced by one or more views, then the privilege should be granted on

any updatable views that reference the table. The grant request to the these

views should be executed as though the current user is _SYSTEM. Similarily

for revokes.

-- If the grant is performed that adds the WITH GRANT OPTION, then

the WITH GRANT OPTION is to be added to the referencing views. The

grant request should be executed as though the current user is _SYSTEM.

Similarily for revokes.

-- The problem was caused by the incorrect grantor being processed. So, added

a new field to the ObjectUsage structure that tells grant/revoke that

the grantor should be the system user. Also added change to not propagate

update privileges on non updatable views.

-- The checkin fixes object privileges; however, work is still needed to

support column level privileges and a mix between column and object level.

TRAFODION-1773 Internal error to revoke role with restrict option when there is

dependent view

-- There code (PrivMgrRoles) that determines if a specific user that owns

objects whose existence depend upon a privilege granted to the specified role

can be revoked. This code did not consider views as a referenced object type

Cleaned up PrivMgrDesc.h & PrivMgrDesc.cpp:

-- remove unused grantee field

-- added columnOrdinal which will be used to fix column privs for TRAFODION 1761

-- replaced std::bitset<NBR_OF_PRIVS> with the define PrivMgrBitmap

  1. … 14 more files in changeset.
Trafodion-1100 Creator of view in private schema unable to select from view

For private schemas, all objects are owned by the schema owner. If an authID

has create component privilege, they can create objects in other schemas.

However, the owner of the new object is still the schema owner.

When the object creator is not the schema owner, then the schema owner

automatically becomes the owner and the object creator is granted all relevant

privileges on the object WGO.

For views, this was not working correctly.

Also found another issue where column privileges were not being handled

correctly when generating the privileges list.

Problem is described in more detail in the JIRA


CmpSeabaseDDLview - changed the create view code to add privileges for both the

schema owner and the view creator, and fixes the privilege list issue.

PrivMgr - added a helper function to convert an authID to an authName

PrivMgrCommands - changed the API to send in the grantor ID

PrivMgrPrivileges - changed the code to use the passed in grantor

TEST141 - added a new regression test, it is currently skipped until

trafodion-1087 is resolved.

  1. … 11 more files in changeset.
Changes for JIRA TRAFODION-353, 1200, 1214, and 12

1. JIRA Trafodion-353 (Launchpad 1324716):

.traf_authentication_config syntax errors on blank


2. JIRA Trafodion-1200 (Launchpad 1447336):

DB__ROOTROLE now equivalent to DB__ROOT (completed

in this delivery).

3. JIRA Trafodion-1214 (Launchpad 1450122):

LDAPSSL (level 1) now uses TLS_CACERTFILE.

4. JIRA Trafodion-12 - grant revoke enhancements including:

Six new component-level privileges: DML_DELETE, DML_INSERT,


Authorization IDs granted a DML privilege at the system

(SQL_OPERATIONS component-level) have the privilege

on all objects in the Trafodion database.

Users who have the MANAGE_PRIVILEGE component-level privilege

can also grant "WITH GRANT OPTION" any privilege they have.

In addition, they implicitly grant on behalf of the owner when

the GRANTED BY clause is omitted. (Mimics DB__ROOT behavior.)

Tracing had been added (but not yet enabled) to better debug

grant and revoke problems

Column level privilege enforcement has been added and column

level privileges support is enabled.

  1. … 25 more files in changeset.
Part 1 of updates to licensing info in Trafodion source

Added NOTICE.txt file in root directory per ASF guidelines.

Updated copyright text in one directory (core/sql/sqlcomp)

as a test of a tool to update such text. One or more later

check-ins will take care of the remaining directories.

  1. … 63 more files in changeset.
Privilege manager fixes for 1438896 and 1465356

1438896: Internal error during create or replace view

The objectUID check when getting privilege information was not correct.

1465356: Revoke privilege from role returns dependent object error

There is a check in mainline revoke code to determine if the object type is a

view and if the SELECT privilege is no longer applicable. If so, then the

dependent error is returned. However, this code is incorrect and actually the

correct code exists in the gatherViewPrivileges method. The view check has been


  1. … 2 more files in changeset.
Merge remote branch 'core/master'

  1. … 2817 more files in changeset.
Move core into subdir to combine repos

    • -0
    • +343
  1. … 10768 more files in changeset.
Move core into subdir to combine repos

    • -0
    • +308
  1. … 10622 more files in changeset.
Move core into subdir to combine repos

Use: git log --follow -- <file>

to view file history thru renames.

    • -0
    • +349
  1. … 10837 more files in changeset.